defect: mknod fails to add additional nbd devices to system about nbd

[yoe]

Yes, this is working as designed.

NBD (and the userland tools) is older than udev, older than DevFS even. So in the old days (or if you choose not to use udev, not sure if that's even possible anymore these days) you had to run MAKEDEV/mknod manually to create the device nodes so you could talk to the kernel at all. The paragraph before the bit that talks about MAKEDEV in the readme does say "if you're not using udev".

Nowadays that's not longer necessary. I guess it's time to drop the references to MAKEDEV from the README file.

[tarndt]

Thanks. Follow up question then, if I want to create new nbd devices on-demand from my application it sounds like I can't just ignore udev and call the mknod syscall.... How does one create a new nbd device using udev?

[yoe]

You can't, the kernel doesn't support that currently. You need to create all the device nodes you need at module load time.

[tarndt]

Thank you for that important clarification.

My understanding is that the Linux kernel itself can dynamically create devices since this happens with other devices in the system.

Am I correct and understanding that the enhancement to achieve dynamic NDB device provisioning would need to be made to the NBD module in the kernel source tree?

The correct place for submitting such a patch would be the kernel mailing list correct? If so I will follow up there with a patch.

Thanks!

[yoe]

Am I correct and understanding that the enhancement to achieve dynamic NDB device provisioning would need to be made to the NBD module in the kernel source tree?

Yes.

It might require more than just that -- most user space code expects the current behavior, so you may not be able change that without breaking things.

The correct place for submitting such a patch would be the kernel mailing list correct? If so I will follow up there with a patch.

Amongst others; check the MAINTAINERS file. There's a script in the kernel which automates sending patches to the correct location(s).

[tarndt]

It might require more than just that -- most user space code expects the current behavior, so you may not be able change that without breaking things.

That's a good point and something I was considering as well. I'd like to propose the exiting device pre-allocation (controlled by the module load parameter nbds_max and defaulting to 16) would continue to function as it does today to ensure continuity. But that the driver would be augmented by my patch with the additional logic to allow udev (or mknod callers for that matter) to dynamically request further nbdX...n devices to be created on demand. Many of the physical device drivers (that support hot-plug, for example) have the required kernel module code to enable this kind of behavior today. Does this seem reasonable to you as a starting point?

[yoe]

I don't think that should be done by udev. If anything, configuring a new device through the netlink interface when all devices are already in use should trigger that.

That said, I'm the maintainer of the NBD userspace code, but I'm not involved with the kernel, do I suggest you talk to the kernel maintainer of the NBD driver.