On Mon, Nov 02, 2020 at 07:08:37PM +0100, hch@xxxxxx wrote:
> On Mon, Nov 02, 2020 at 04:15:01PM +0000, Javier Gonzalez wrote:
> > That said, I don't mind the concept, though I recall Christoph had
> > concerns about the existing 0-capacity namespace used for invalid
> > formats, so I'd like to hear more on that if he has some spare time to
> > comment.
>
> Yes, I really don't think 0 sized block devices are the right interface
> for namespaces we can't access. I think the proper fix is to ensure that
> we have a character device that allows submitting I/O commands for each
> namespaces including those where we don't understand the I/O command set
> or parts of it. That should also really help to have a proper access
> model for the KV command set. Initially we only need NVME_IOCTL_IO64_CMD,
> but eventually we'll need some support for async submissions, be
> that through io_uring or other ways.
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.
