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?
