On Mon, Mar 01, 2021 at 08:24:51PM +0100, javier@xxxxxxxxxxx wrote: > From: Javier González <javier.gonz@xxxxxxxxxxx> > > Create a char device per NVMe namespace. This char device is always > initialized, independently of whether the features implemented by the > device are supported by the kernel. User-space can therefore always > issue IOCTLs to the NVMe driver using the char device. > > The char device is presented as /dev/nvme-generic-XcYnZ. This naming > scheme follows the convention of the hidden device (nvmeXcYnZ). Support > for multipath will follow. So I'm a little worried about the "support for multipath will follow" as this has implications for the naming scheme, and our policy of how we allow access to a namespace. 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 Which also makes me wonder about patch 2 in the series that seems somewhat dangerous. Can we clearly state the policy implemented?
