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

[Christoph Hellwig]

On Wed, Mar 03, 2021 at 11:02:12AM +0100, Javier González wrote:
>> 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?

So trying to follow the code:

 - nvme_cdev_fops implements file operations that directly on a nvme_ns,
   so they are path specific
 - we allow opening them even for a hidden controller
 - there does not seem to be a char device node for ns_head at all.