Re: [Nbd] [PATCH 4/4] nbd: add a nbd-control interface
- To: Josef Bacik <jbacik@...2204...>
- Cc: axboe@...2204..., nbd-general@lists.sourceforge.net, kernel-team@...2204..., linux-block@...25..., arnd@...2332...
- Subject: Re: [Nbd] [PATCH 4/4] nbd: add a nbd-control interface
- From: Greg KH <gregkh@...1299...>
- Date: Mon, 23 Jan 2017 16:03:25 +0100
- Message-id: <20170123150325.GB26884@...926...>
- In-reply-to: <1485183472.21123.0@...2791...>
- References: <1484949412-6903-1-git-send-email-jbacik@...2204...> <1484949412-6903-4-git-send-email-jbacik@...2204...> <20170121090531.GB27048@...926...> <1485182528.9861.22@...2791...> <20170123145212.GA19582@...926...> <1485183472.21123.0@...2791...>
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@...1299...> 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@...1299...> 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@...2204...>
> > > >
> > > > 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 :(
Reply to: