[PATCH v2] util: basic support for VFIO variant drivers

Jason Gunthorpe jgg at nvidia.com
Wed Aug 24 00:05:39 UTC 2022


On Tue, Aug 23, 2022 at 01:51:33PM -0600, Alex Williamson wrote:
> On Tue, 23 Aug 2022 10:11:32 -0400
> Laine Stump <laine at redhat.com> wrote:
> 
> > ping.
> > 
> > I have a different version of this patch where I do read the 
> > modules.alias file rather than just checking the name of the driver, but 
> > that also requires "double mocking" open() in the unit test, which 
> > wasn't working properly, and I'd rather not spend the time figuring it 
> > out if it's not going to be needed. (Alex prefers that version because 
> > it is more correct than just checking the name, and he's concerned that 
> > the new sysfs-based API may take longer than we're thinking to get into 
> > downstream distros, but the version in this patch does satisfy both 
> > Jason and Daniel's suggested implementations). Anyway, I can post the 
> > other patch if anyone is interested.
> 
> Yeah, I'm still not a fan of this approach.  We're essentially
> inventing a requirement in libvirt for a kernel driver naming
> convention, because it happens to work.  For now.  Hacky temporary
> solutions have been known to be longer lived than anticipated.  This
> eventually deteriorates into managing a list of drivers that don't meet
> the convention, frustrating developers unaware of this arbitrary
> requirement and/or delaying usability through libvirt.  Thanks,

Kevin&co has some patches already to do the struct device sysfs, I
hope he can post them, thet looked quite close last I saw. Lets give
him a few weeks - having that in hand removes the worry about
endlessly hacky into the future.

Jason



More information about the libvir-list mailing list