From: Kanchan Joshi <joshiiitr@gmail.com>
To: Niklas Cassel <Niklas.Cassel@wdc.com>
Cc: "Minwoo Im" <minwoo.im.dev@gmail.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"Keith Busch" <kbusch@kernel.org>, "Jens Axboe" <axboe@fb.com>,
"Christoph Hellwig" <hch@lst.de>,
"Sagi Grimberg" <sagi@grimberg.me>,
"Javier González" <javier.gonz@samsung.com>
Subject: Re: [PATCH V2 0/1] nvme: introduce generic per-namespace chardev
Date: Tue, 6 Apr 2021 19:43:03 +0530 [thread overview]
Message-ID: <CA+1E3rKVS4dXNSPKojchqA4vbxmLhs=EBBk7=zAsbYFcR-TeBw@mail.gmail.com> (raw)
In-Reply-To: <YGwjc8rliXhvccPp@x1-carbon.lan>
On Tue, Apr 6, 2021 at 2:33 PM Niklas Cassel <Niklas.Cassel@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.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
prev parent reply other threads:[~2021-04-06 14:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-06 6:48 [PATCH V2 0/1] nvme: introduce generic per-namespace chardev Minwoo Im
2021-04-06 6:48 ` [PATCH V2 1/1] " Minwoo Im
2021-04-07 13:15 ` Christoph Hellwig
2021-04-07 14:11 ` Minwoo Im
2021-04-07 14:21 ` Christoph Hellwig
2021-04-07 15:35 ` Minwoo Im
2021-04-07 15:40 ` Christoph Hellwig
2021-04-07 15:44 ` Minwoo Im
2021-04-07 15:47 ` Minwoo Im
2021-04-07 16:48 ` Christoph Hellwig
2021-04-07 16:59 ` Minwoo Im
2021-04-07 17:09 ` Minwoo Im
2021-04-07 17:14 ` Christoph Hellwig
2021-04-08 7:11 ` Javier González
2021-04-08 7:26 ` Christoph Hellwig
2021-04-08 10:26 ` Javier González
2021-04-08 11:27 ` Christoph Hellwig
2021-04-08 11:46 ` Javier González
2021-04-08 12:41 ` Minwoo Im
2021-04-06 9:01 ` [PATCH V2 0/1] " Niklas Cassel
2021-04-06 13:35 ` Minwoo Im
2021-04-06 14:59 ` Christoph Hellwig
2021-04-06 16:23 ` Minwoo Im
2021-04-07 6:00 ` Christoph Hellwig
2021-04-07 6:02 ` Minwoo Im
2021-04-07 7:36 ` Niklas Cassel
2021-04-07 9:39 ` Christoph Hellwig
2021-04-07 10:00 ` Niklas Cassel
2021-04-07 10:34 ` Damien Le Moal
2021-04-07 11:50 ` Javier González
2021-04-06 14:13 ` Kanchan Joshi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+1E3rKVS4dXNSPKojchqA4vbxmLhs=EBBk7=zAsbYFcR-TeBw@mail.gmail.com' \
--to=joshiiitr@gmail.com \
--cc=Niklas.Cassel@wdc.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=javier.gonz@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=minwoo.im.dev@gmail.com \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).