[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