[PATCH V6 1/2] nvme: enable char device per namespace

Javier González javier at javigon.com
Wed Mar 3 10:02:12 GMT 2021


On 03.03.2021 10:10, Christoph Hellwig wrote:
>On Mon, Mar 01, 2021 at 08:24:51PM +0100, javier at javigon.com wrote:
>> From: Javier González <javier.gonz at samsung.com>
>>
>> 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?



More information about the Linux-nvme mailing list