Re: [PATCH 2/4] miscdevice: add a minor number for nbd-control
> On Jan 21, 2017, at 4:03 AM, Greg KH wrote: > >> On Fri, Jan 20, 2017 at 04:56:50PM -0500, Josef Bacik wrote: >> NBD is moving to a loop-control esque way of managing it's device >> creation and deletion. Reserver a minor number for the new device. >> >> Signed-off-by: Josef Bacik >> --- >> include/linux/miscdevice.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h >> index ed30d5d..7e5c140 100644 >> --- a/include/linux/miscdevice.h >> +++ b/include/linux/miscdevice.h >> @@ -44,6 +44,7 @@ >> #define MISC_MCELOG_MINOR227 >> #define HPET_MINOR228 >> #define FUSE_MINOR229 >> +#define NBD_CTRL_MINOR230 > > Ick, really? Why not just use a dynamic one? What 1990's-based systems > are you running that you would need a static misc device number for? > Honestly I was just doing what loop did, I wasn't sure if there was some administration reason for needing a static minor number. If nobody cares then I can just use a dynamic one. Thanks, Josef-- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Nbd] [PATCH 4/4] nbd: add a nbd-control interface
> On Jan 21, 2017, at 7:12 AM, Wouter Verhelst wrote: > >> On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote: >> This patch mirrors the loop back device behavior with a few changes. First >> there is no DEL operation as NBD doesn't get as much churn as loop devices >> do. >> Secondly the GET_NEXT operation can optionally create a new NBD device or >> not. >> Our infrastructure people want to not allow NBD to create new devices as it >> causes problems for them in containers. However allow this to be optional as >> things like the OSS NBD client probably doesn't care and would like to just >> be >> given a device to use. > > Don't be so sure :-) > > I agree that having a control device for NBD is useful and would make > certain things much easier. If that's added, then I'll move to using > that as a way to control the device rather than opening a device and > dealing with it that way. In fact, at some point in the past I did > suggest something along those ways myself; it's just not happened yet. > > Obviously though this would require an intermediate situation in which > the control master would be available as well as (optionally perhaps) > the old way where you open a specific device node, so that we don't > break existing implementations before they've had a chance to follow > suit. Sorry I wasn't super clear. This doesn't change anything about how the devices are setup, it just means if you do max_nbds=0 you can dynamically add more as you need them, and you can find unused nbd devices easily instead of making the user specify them. When I get home tonight I'll push my nbd-client patch so you can see how I use it. Thanks, Josef-- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Nbd] [PATCH 4/4] nbd: add a nbd-control interface
On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote: > This patch mirrors the loop back device behavior with a few changes. First > there is no DEL operation as NBD doesn't get as much churn as loop devices do. > Secondly the GET_NEXT operation can optionally create a new NBD device or not. > Our infrastructure people want to not allow NBD to create new devices as it > causes problems for them in containers. However allow this to be optional as > things like the OSS NBD client probably doesn't care and would like to just be > given a device to use. Don't be so sure :-) I agree that having a control device for NBD is useful and would make certain things much easier. If that's added, then I'll move to using that as a way to control the device rather than opening a device and dealing with it that way. In fact, at some point in the past I did suggest something along those ways myself; it's just not happened yet. Obviously though this would require an intermediate situation in which the control master would be available as well as (optionally perhaps) the old way where you open a specific device node, so that we don't break existing implementations before they've had a chance to follow suit. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12 -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] nbd: add a nbd-control interface
On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote: > This patch mirrors the loop back device behavior with a few changes. First > there is no DEL operation as NBD doesn't get as much churn as loop devices do. > Secondly the GET_NEXT operation can optionally create a new NBD device or not. > Our infrastructure people want to not allow NBD to create new devices as it > causes problems for them in containers. However allow this to be optional as > things like the OSS NBD client probably doesn't care and would like to just be > given a device to use. > > Signed-off-by: Josef Bacik A random char device with odd ioctls? Why? There's no other configuration choice you could possibly use? Where is the userspace tool that uses this new kernel api? You aren't passing in structures to the ioctl, so why does this HAVE to be an ioctl? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] miscdevice: add a minor number for nbd-control
On Fri, Jan 20, 2017 at 04:56:50PM -0500, Josef Bacik wrote: > NBD is moving to a loop-control esque way of managing it's device > creation and deletion. Reserver a minor number for the new device. > > Signed-off-by: Josef Bacik > --- > include/linux/miscdevice.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h > index ed30d5d..7e5c140 100644 > --- a/include/linux/miscdevice.h > +++ b/include/linux/miscdevice.h > @@ -44,6 +44,7 @@ > #define MISC_MCELOG_MINOR227 > #define HPET_MINOR 228 > #define FUSE_MINOR 229 > +#define NBD_CTRL_MINOR 230 Ick, really? Why not just use a dynamic one? What 1990's-based systems are you running that you would need a static misc device number for? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
