On 01/25/2017 03:30 PM, Greg KH wrote: >> Given (because of NBD_DO_IT) we need an ioctl anyway, and we have >> an ioctl that isn't going to go away, it would seem better if possible >> to stick with ioctls, and not introduce either a dependency >> on netlink (which would presumably bloat static binaries that >> are used early in the boot process). Personally I'd have thought >> adding a new NBD ioctl (or extending an existing one) would be >> less entropy than adding a new char device. > > Why can't you just do this on any existing nbd block device with an > ioctl to it? No need to have to do it on an out-of-band char device > node, right? How do you get an fd to existing nbd block device? Your intent is to use an ioctl to request creating/opening a new nbd device that no one else is using; opening an existing device in order to send that ioctl may have negative ramifications to the actual user of that existing device, if not permissions issues that prevent the open from even happening. Having a separate control fd makes it obvious that you are asking for a new nbd device, and don't want to stomp on any existing devices. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
