On Tue, Dec 01, 2020 at 07:57:32PM +0100, Javier González wrote: > On 01.12.2020 23:03, Minwoo Im wrote: > > > + > > > + device_initialize(&ns->cdev_device); > > > + ns->cdev_device.devt = MKDEV(MAJOR(nvme_ns_base_chr_devt), > > > + ns->head->instance); > > > + ns->cdev_device.class = nvme_ns_class; > > > + ns->cdev_device.parent = ctrl->device; > > > + ns->cdev_device.groups = nvme_ns_char_id_attr_groups; > > > + dev_set_drvdata(&ns->cdev_device, ns); > > > + > > > + sprintf(cdisk_name, "nvme%dc%dn%d", ctrl->subsys->instance, > > > + ctrl->instance, ns->head->instance); > > > > In multi-path, private namespaces for a head are not in /dev, so I don't > > think this will hurt private namespaces (e.g., nvme0c0n1), But it looks > > like it will make a little bit confusions between chardev and hidden blkdev. > > > > I don't against to update nvme-cli things also even naming conventions are > > going to become different than nvmeXcYnZ. > > Agree. But as I understand it, Keith had a good argument to keep names > aligned with the hidden bdev. My suggested naming makes it as obvious as possible that the character device in /dev/ and the hidden block device in /sys/ are referring to the same thing. What is confusing about that? > It is also true that in that comment he suggested nesting the char > device in /dev/nvme Yeah, I'm okay with sub-directories for these special handles, but there are arguments against it too. I don't feel that strongly about it either way.
