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,
