[PATCH] util: basic support for vendor-specific vfio drivers

Daniel P. Berrangé berrange at redhat.com
Fri Aug 5 15:59:29 UTC 2022


On Fri, Aug 05, 2022 at 11:46:17AM -0400, Laine Stump wrote:
> On 8/5/22 5:40 AM, Daniel P. Berrangé wrote:
> > On Mon, Aug 01, 2022 at 09:30:38AM -0400, Laine Stump wrote:
> > > On 8/1/22 7:58 AM, Erik Skultety wrote:
> > > > 
> > > > Instead of calling an external program and then grepping its output which
> > > > technically could change in the future, wouldn't it be better if we read
> > > > /lib/modules/`uname -r`/modules.alias and filtered whatever line had the
> > > > vfio-pci' substring and compared the module name with the user-provided device
> > > > driver?
> > > 
> > > Again, although I was hesistant about calling an external command, and asked
> > > if there was something simpler, Alex still suggested modinfo, so I'll let
> > > him answer that. Alex?
> > > 
> > > (Also, although the format of the output of "uname -r" is pretty much
> > > written in stone, you're still running an external command :-))
> > 
> > You wouldn't  actually call 'uname -r', you'd invoke uname(2) function
> > and use the 'release' field in 'struct utsname'.
> 
> Yeah, I wasn't thinking clearly when I said that :-P
> 
> > 
> > I'd favour reading modules.alias directly over invoking modinfo for
> > sure, though I'd be even more in favour of the kernel just exposing
> > the sysfs attribute and in the meanwhile just hardcoding the only 2
> > driver names that exist so far.
> 
> The problem with hardcoding the 2 existing driver names is that it wouldn't
> do any good to anyone developing a new driver, and part of the aim of doing
> this is to make it possible for developers to test their new drivers using
> libvirt (and management systems based on libvirt).

I'm only suggesting hardcoding the driver names, *if* the kernel folks
agree to expose the sysfs directory.  Anyone developing new drivers
is unlikely to have their drivers merged before this new sysfs dir
is added, so it is not a significant enough real world blocker for them
for us to worry about. Best to focus on what the best long term
approach is, and not worry about problems that will only exist for
a couple of kernel releases today.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the libvir-list mailing list