On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote: > > > That is reasonable, but I'd say those three kernels only have two > > > drivers and they both have vfio as a substring in their name - so the > > > simple thing of just substring searching 'vfio' would get us over that > > > gap. > > > > Looking at the aliases for exactly "vfio_pci" isn't that much more > > complicated, and "feels" a lot more reliable than just doing a substring > > search for "vfio" in the driver's name. (It would be, uh, .... "not > > smart" to name a driver "vfio<anything>" if it wasn't actually a vfio > > variant driver (or the opposite), but I could imagine it happening; :-/) This is still pretty hacky. I'm worried about what happens to the kernel if this becames some crazy unintended uAPI that we never really thought about carefully... This was not a use case when we designed the modules.alias stuff at least. BTW - why not do things the normal way? 1. readlink /sys/bus/pci/devices/XX/iommu_group 2. Compute basename of #1 3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2) It has a small edge case where a multi-device group might give a false positive for an undrivered device, but for the purposes of libvirt that seems pretty obscure.. (while the above has false negative issues, obviously) > > Since we already need to do something else as a stop-gap for the interim > > (in order to avoid making driver developers wait any longer if for no > > other reason), my opinion would be to not spend extra time splitting up > > patches just to give us this functionality slightly sooner; we'll anyway > > have something at least workable in place. > > We also need to be careful in adding things piecemeal that libvirt can > determine when new functionality, such as vfio device chardevs, are > actually available and not simply a placeholder to fill a gap > elsewhere. In sysfs the kernel standard is the directory means there is a "struct device" and the "dev" file within the directory means there is a cdev, so it is safely discoverable. I would like to split the kernel patch anyhow because the cdev is conceptually complicated so having just the struct device bits on its own would be helpful.. Jason
