From: "hch@lst.de" <hch@lst.de>
To: Javier Gonzalez <javier@javigon.com>
Cc: "hch@lst.de" <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"joshi.k@samsung.com" <joshi.k@samsung.com>,
"Klaus B. Jensen" <k.jensen@samsung.com>,
"Niklas.Cassel@wdc.com" <Niklas.Cassel@wdc.com>
Subject: Re: nvme: report capacity 0 for non supported ZNS SSDs
Date: Tue, 3 Nov 2020 16:26:09 +0100 [thread overview]
Message-ID: <20201103152609.GA10928@lst.de> (raw)
In-Reply-To: <20201103141019.5eomaxs4qn4ezaeh@MacBook-Pro.localdomain>
On Tue, Nov 03, 2020 at 03:10:19PM +0100, Javier Gonzalez wrote:
> One question here is that we are preparing a RFC for a io_uring passthru
> using the block device. Based on this discussion, it seems to me that
> you see this more suitable through the char device.
>
> Does it make sense that we post this RFC using the block device? It
> would be helpful to get early feedback before starting the char device.
If you wan to send the RFC with the block device that is ok. But I
think the separate character device is pretty trivial, at least for
NVM command set derived command sets like ZNS (for others we'll need
to finish the Command Set Independent Identify Namespace TP first).
> I see that this does not make much sense for the other non-supported
> features in this patch (i.e., !po2 zone size and zoc). Since this is
> very much like PI today, is it OK we add these the same way (capacity 0)
> and then move to the char device when ready?
I'd rath avoid adding more of that capacity 0 mess if we can. Especially
as the character device should be really easy to do.
next prev parent reply other threads:[~2020-11-03 15:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20201102161505eucas1p19415e34eb0b14c7eca5a2c648569cf1e@eucas1p1.samsung.com>
[not found] ` <0916865d50c640e3aa95dc542f3986b9@CAMSVWEXC01.scsc.local>
2020-11-02 16:30 ` [PATCH V2] nvme: report capacity 0 for non supported ZNS SSDs Niklas Cassel
2020-11-02 21:25 ` Javier Gonzalez
2020-11-02 18:08 ` [PATCH V2] " hch
2020-11-02 18:33 ` Keith Busch
2020-11-02 18:58 ` hch
2020-11-02 21:24 ` Javier Gonzalez
2020-11-03 9:06 ` hch
2020-11-03 14:10 ` Javier Gonzalez
2020-11-03 15:26 ` hch [this message]
2020-11-03 15:54 ` Javier Gonzalez
2020-11-04 14:26 ` [PATCH V2] " Hannes Reinecke
2020-11-04 14:29 ` hch
2020-11-04 14:46 ` Hannes Reinecke
2020-11-05 7:37 ` hch
2020-11-05 7:42 ` Hannes Reinecke
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=20201103152609.GA10928@lst.de \
--to=hch@lst.de \
--cc=Niklas.Cassel@wdc.com \
--cc=axboe@kernel.dk \
--cc=javier@javigon.com \
--cc=joshi.k@samsung.com \
--cc=k.jensen@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--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).