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

["Javier González" <javier@javigon.com>]

On 09.03.2021 12:31, Christoph Hellwig wrote:
>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

This is correct.

> - we allow opening them even for a hidden controller

This is also correct.

> - there does not seem to be a char device node for ns_head at all.

Also correct.

We tried to keep it simple in the first iteration. Am I understanding
that you see necessary to have per ns_head char devices?