On Thu, Jul 25, 2019 at 01:24:22PM -0600, Logan Gunthorpe wrote: > > > On 2019-07-25 1:11 p.m., Matthew Wilcox wrote: > > On Thu, Jul 25, 2019 at 12:05:29PM -0700, Sagi Grimberg wrote: > >> > >>>>> 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. > >>>> > >>>> Why isn't a fd being passed in there instead of a random string? > >>> > >>> I suppose we could echo a string of the file descriptor number there, > >>> and look up the fd in the process' file descriptor table ... > >> > >> Assuming that there is a open handle somewhere out there... > > Yes, that would be a step backwards from an interface. The user would > then need a special process to open the fd and pass it through configfs. > They couldn't just do it with basic bash commands. First of all, they can, but... WTF not have filp_open() done right there? Yes, by name. With permission checks done. And pick your object from the sodding struct file you'll get. What's the problem? Why do you need cdev lookups, etc., when you are dealing with files under your full control? Just open them and use ->private_data or whatever you set in ->open() to access the damn thing. All there is to it...
