On 02.11.2020 19:58, hch@xxxxxx wrote:
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.
This sounds reasonable. We have been back and forth on a patchset with async passthru using io_uring. I believe this can help with some of the questions we are preparing for a RFC. If I understand correctly, the model would be that a namespace will always have (i) a character device associated where I/O is always allowed through user formed commands, and if the namespace has full support in the kernel (ii) a block device where I/O is as it is today. In case of (ii) both interfaces can be used for I/O. While we work on iterations for c), do you believe it is reasonable to merge a version of the current path that follows the PI convention for unsupported command sets and features? I would assume that we will have to convert PI to this model too when it is available. Javier
