On 2019-07-25 12:08 p.m., Greg Kroah-Hartman wrote: > On Thu, Jul 25, 2019 at 11:53:20AM -0600, Logan Gunthorpe wrote: >> >> >> On 2019-07-25 11:40 a.m., Greg Kroah-Hartman wrote: >>> On Thu, Jul 25, 2019 at 11:23:21AM -0600, Logan Gunthorpe wrote: >>>> cdev_get_by_path() attempts to retrieve a struct cdev from >>>> a path name. It is analagous to blkdev_get_by_path(). >>>> >>>> This will be necessary to create a nvme_ctrl_get_by_path()to >>>> support NVMe-OF passthru. >>> >>> Ick, why? Why would a cdev have a "pathname"? >> >> So we can go from "/dev/nvme0" (which points to a char device) to its >> struct cdev and eventually it's struct nvme_ctrl. Doing it this way also >> allows supporting symlinks that might be created by udev rules. > > Why do you have a "string" within the kernel and are not using the > normal open() call from userspace on the character device node on the > filesystem in your namespace/mount/whatever? NVMe-OF is configured using configfs. The target is specified by the user writing a path to a configfs attribute. This is the way it works today but with blkdev_get_by_path()[1]. For the passthru code, we need to get a nvme_ctrl instead of a block_device, but the principal is the same. > Where is this random string coming from? configfs > Why is this so special that no > one else has ever needed it? People have needed the same functionality for block devices and blkdev_get_by_path() has multiple users (iscsi, drbd, nvme-of, etc) which are doing similar things. Nobody has needed to do the same with a chardev until we wanted the NVMe-of to support targeting an NVMe controller which is represented in userspace by a char device. Logan [1] https://elixir.bootlin.com/linux/latest/source/drivers/nvme/target/io-cmd-bdev.c#L15
