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...
Oh this is so much simpler. There is really no point in using anything
else. Just need to remember to compare f->f_op to what we expect to make
sure that it is indeed the same device class.
