On Mon, Jan 23, 2017 at 09:57:52AM -0500, Josef Bacik wrote: > On Mon, Jan 23, 2017 at 9:52 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jan 23, 2017 at 09:42:08AM -0500, Josef Bacik wrote: > > > > > > > > > On Sat, Jan 21, 2017 at 4:05 AM, Greg KH > > > <gregkh@xxxxxxxxxxxxxxxxxxx> 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. > > > > > > > > > > Signed-off-by: Josef Bacik <jbacik@xxxxxx> > > > > > > > > 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? > > > > > > Again, this is how loop does it so I assumed a known, regularly > > > used API was > > > the best bet. I can do literally anything, but these interfaces > > > have to be > > > used by other people, including internal people. The > > > /dev/whatever-control > > > is a well established way for interacting with dynamic device > > > drivers (loop, > > > DM, btrfs), so that's what I went with. Thanks, > > > > Again, please don't duplicate what loop did, we must _learn_ from > > history, not repeat it :( > > Sure but what am I supposed to do? Have some random sysfs knobs? Thanks, It all depends on what you are trying to do. I have yet to figure that out at all here :( -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
