[PATCH V2 0/1] nvme: introduce generic per-namespace chardev

[Kanchan Joshi]

On Tue, Apr 6, 2021 at 2:33 PM Niklas Cassel <Niklas.Cassel at wdc.com> wrote:
>
> On Tue, Apr 06, 2021 at 03:48:40PM +0900, Minwoo Im wrote:
> > Hello,
> >
> > This is the second patch series to support generic ns character device
> > to expose per-namespace instance to the userspace.  This version fixed
> > code mis-ordered reported by Kanchan.
> >
> > This patch introduces per-namespace character device to I/O in case that
> > blkdev is not initialized properly.  Userspace applications are able to
> > I/O to the generic namespace chardev even there's no blkdev properly
> > initialized.  Because we don't allow nvme controller device to I/O with
> > a specified nsid, this generic device will provide a way to I/O.
> >
> > This patch is derived from Javier's patch series [1].  Javier and I have
> > re-coded this series again and it starts with new version tag.  Changes
> > from the previous series are:
> >
> >   - Update naming convention for the chardev exactly the same with the
> >     blkdev:
> >         /dev/nvme-generic-XcYnZ  to  /dev/nvme-generic-XnY
>
> Hello Minwoo,
>
> The current proposal puts these new per-ns char devs in directly in
> /dev/ (I assume since Christoph didn't like the /dev/nvme/ subdir idea.
> Keith seemed to like the subdir idea, since he had suggested the same.)
>
> For the absolute majority of cases, the namespace will not be rejected,
> so the user will be able to use the per-ns block dev to perform IOCTLs.
>
> For the small minority of cases, Linux might reject the ns, so no block
> dev will be created.
>
> I'm slightly worried that adding all these new per-ns char devs, in the
> same directory as the regular per-ns block devs, will lead to confusion
> from regular Linux users.
>
> Imagine the potential confusion about what device the user should use
> with e.g. fdisk, mkfs, mount, in fstab, what to specify in fstab, etc.
>
> I think that there is value in reducing the confusion for regular users.
>
>
>
> I don't know the best way of reducing this potential confusion, but here
> are some suggestions (suggestions are mutually exclusive):
>
> 1) Put the new per-ns char devs in a directory different from where
> the regular per-ns block devs are located.
>
> 2) Only create the new per-ns char dev for namespaces that were rejected.
>
> 3) There is already a new module parameter for this, default it to false.
>
> 4) Introduce a sysfs /sys/class/nvme/nvme0/export_unsupported_namespace
> that you can echo the nsid to, if you want to create the new per-ns char
> dev for a certain ns.
>
>
> I'm certain that someone can come up with an even better suggestion.

While 1 sounds good, the problem with 2, 3 and 4 is that it will make
things difficult for applications which want to use the new interface
(i.e. char device).
When char-device is always available/visible, it is more
automatic......applications can use it all the time without resorting
to any extra administrative tunable.