Re: [PATCH V2] nvme: report capacity 0 for non supported ZNS SSDs

From: "hch@lst.de" <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: "hch@lst.de" <hch@lst.de>,
	Javier Gonzalez <javier.gonz@samsung.com>,
	"javier@javigon.com" <javier@javigon.com>,
	"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: [PATCH V2] nvme: report capacity 0 for non supported ZNS SSDs
Date: Mon, 2 Nov 2020 19:58:51 +0100	[thread overview]
Message-ID: <20201102185851.GA21349@lst.de> (raw)
In-Reply-To: <20201102183355.GB1970293@dhcp-10-100-145-180.wdc.com>

On Mon, Nov 02, 2020 at 10:33:55AM -0800, Keith Busch wrote:
> I can see this going one of two ways:
> 
>  a) Set up the existing controller character device with a generic
>     disk-less request_queue to the IO queues accepting IO commands to
>     arbitrary NSIDs.
> 
>  b) Each namespace that can't be supported gets their own character
>     device.
> 
> I'm leaning toward option "a". While it doesn't create handles to unique
> namespaces, it has more resilience to potentially future changes. And I
> recall the target side had a potential use for that, too.

The problem with a) is that it can't be used to give users or groups
access to just one namespaces, so it causes a real access control
nightmare.  The problem with b) is that now applications will break
when we add support for new command sets or features.  I think

  c) Each namespace gets its own character device, period.

is the only sensible option.