[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