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

On 09.03.2021 12:31, Christoph Hellwig wrote:

On Wed, Mar 03, 2021 at 11:02:12AM +0100, Javier González wrote:

quoted

quoted

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).

quoted

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?