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,
Josef
--
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
