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.
