On 03.03.2021 10:10, Christoph Hellwig wrote:
On Mon, Mar 01, 2021 at 08:24:51PM +0100, javier@xxxxxxxxxxx wrote:
From: Javier González <javier.gonz@xxxxxxxxxxx>
Create a char device per NVMe namespace. This char device is always
initialized, independently of whether the features implemented by the
device are supported by the kernel. User-space can therefore always
issue IOCTLs to the NVMe driver using the char device.
The char device is presented as /dev/nvme-generic-XcYnZ. This naming
scheme follows the convention of the hidden device (nvmeXcYnZ). Support
for multipath will follow.
So I'm a little worried about the "support for multipath will follow" as
this has implications for the naming scheme, and our policy of how we
allow access to a namespace.
I maintained the message to follow the original commit. In this
patchset multipath is implemented. I maintains the same naming scheme.
We can remove this comment as multipath is supported in the existing
series.
Ignoring some of the deprecated historic mistakes I think the policy
should be:
- admin commands that often are controller specific should usually
go to a controller-specific device, the existing /dev/nvmeX
devices
- I/O commands and admin command that do specific a nsid should go
through a per-namespace node that is multipath aware and not
controller specific
Sounds good.
The current implementation re-routes IOCTLs to the char device through
the existing bdev IOCTLs, so I believe we follow this policy already. We
basically default to current behavior.
And I assume that for legacy, namespace IOCTLs to the controller will
still be routed to the namespace (assuming a single namespace).
Which also makes me wonder about patch 2 in the series that seems
somewhat dangerous. Can we clearly state the policy implemented?
Patch 2 is the one that exposes the existing logic for multipath. How do
you think we should do it instead?
