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

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).