[PATCH 13/13] nvme: introduce generic per-namespace chardev

Minwoo Im minwoo.im.dev at gmail.com
Fri Apr 9 12:24:01 BST 2021


On 21-04-09 11:52:05, Christoph Hellwig wrote:
> On Fri, Apr 09, 2021 at 05:02:14PM +0900, Minwoo Im wrote:
> > On 21-04-09 09:54:15, Christoph Hellwig wrote:
> > > On Fri, Apr 09, 2021 at 04:29:01PM +0900, Minwoo Im wrote:
> > > > Tested with namespace-specific admin commmand (Identify Namespace).  And
> > > > it fails with invalid IOCTl because we don't have a route to the
> > > > controller IOCTL for the generic chrdev.
> > > 
> > > Yes, that is intentional, as supporting the per-controller ioctls
> > > on the per-namespace devices is a mess.
> > 
> > In multipath case, head blkdev is also per-namespace node which is now
> > supporting the controller ioctl by nvme_find_get_live_ctrl().  Is there
> > any different policy between the existing blkdev and generic device in
> > the current series ? Or should be just deprecate the controller ioctl
> > from the head blkdev ioctl in multipath case ?
> 
> Well, the multipath block device is supposed to be a full drop in
> for the block device, including having the same name.  So I don't think
> we can just deprecate it, even if that would really improve things.

I think if we don't have a route to the live controller from the
multipath node /dev/ng0n1, how does application figure out controller
node to request admin commands like Identify Namespace before their
own I/O ?

We have sysfs, but it does not provide every information about the
namespace.  Or is there any charming way to find out the live
controller from a head node through sysfs or something that I missed
here ? :)



More information about the Linux-nvme mailing list