On Thu, Feb 05, 2015 at 09:24:00AM +0000, Alex Bligh wrote: > > On 5 Feb 2015, at 08:18, Wouter Verhelst <w@...112...> wrote: > > > I had been thinking it might make sense for NBD to have something like > > an "nbd master", in the style of /dev/pts/ptmx; a /dev node whom you ask > > for an NBD device assignment, and which replies with a name, or > > something along those lines. > > /dev/tun is another similar (and from what I recall slightly simpler) > precedent. Yes I also thought about something similar for nbd. > > > The problem, as ever, is backwards compatibility. If taken to its > > logical extreme, this nbdmaster devnode would exist from module > > initialization, but things like /dev/nbd0 etc wouldn't be, only when > > they are registered. That would not be backwards compatible... > > OK, how about this for a route to backward compatibility. > > Currently the /dev/nbdN devices only appear when the nbd module is > first loaded, via udev or whatever, when the relevant device nodes > are created. As standard, 16 of these are created. Access to these > devices is inherently racy for the reasons described above. Let's > call these 'static' nbd devices. > > As a replacement, we make the nbd module create N (where N is > a configurable number on the module command line inititially > defaulting to 16, but may become zero later) such devices which > are static nbd devices. These work as normal. We also let it > create dynamic nbd devices (meaning those mediated by the > /dev/nbd control device). These could be numbered from N up, > though numbering them with a gap might be useful to avoid > naive software relying on the old scheme enumerating from > 0 upwards. > > Userland software, over time, can be converted to use /dev/nbd > if it exists to safely create nbd devices. If it finds /dev/nbd > is absent, it can fall back to the old route. > > Eventually, the default value of N can be reduced to zero, > in which case only the new route will work. This default value > could be a kernel compile option, in which case a distro that > is confident it has refreshed all its nbd software could if > it wished reduce N to zero earlier than the mainline kernel. I think there should be a kernel deprecation warning with each connection of a static nbd device before reducing the default number of nbd devices. Otherwise users may experience unexpected difficulties after a reboot into a newer kernel. If they get warnings with every nbd device connection they may have a look at the new way of allocating nbd devices and fix their programs. Best Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: Digital signature