On 03.11.2020 10:06, hch@xxxxxx wrote:
On Mon, Nov 02, 2020 at 10:24:05PM +0100, Javier Gonzalez wrote:
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.
Yes.
Thanks for confirming.
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.
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.
I'm rather torn. I think the model of the zero capacity block device
is a really, really bad one and we should haver never added it. That
being said, for a ZNS namespace that does not support Zone Append I
can think of a model that actually makes sense: expose it as a read-only
block device, as we can actually read from it perfectly fine, and that
would also allow ioctl access.
This is reasonable. I can re-spin this for append to become read-only
and then we work in parallel for the char device interface.
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?
