On Thu, Oct 29, 2015 at 10:33:57AM +0200, Yan Vugenfirer wrote: > > On 29 Oct 2015, at 10:28, Richard W.M. Jones <[email protected]> wrote: > > On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > > > > Seems like looking at this field in the .inf file is better than our > > current approach of matching path names. > > You just need to remember that we have binary compatible versions of > drivers. For example virtio-net driver for Windows 2012 (Windows 8) > (6.2) will be used for Windows 2012R2 (Windows 8.1) and Windows Server > 2016 (Windows 10). So you are getting the lowest compatible version of > the OS from INF file.
That seems to match Vadim's description: > >> If you found an inf file with the matching minor OS (6 in our case) > >> version and matching or less but close minor version number (2 vs 3) > >> then you are in the right directory. and it's OK as it's an algorithm that can be coded and made to work reliably. However, do I get it right that this is just a convention currently followed in virtio-win drivers? I.e. there's nothing in the Windows driver specifications mandating this versioning scheme? I'm trying to figure out how dependable it is. Besides, ATM there's at least one driver -- qemupciserial -- which doesn't fit in this scheme (or any scheme at all :). There are other peculiarities which we don't know what to do: - the netkvm driver directory on virtio-win.iso contains netkvmco.dll (I'm assuming it's coinstaller dll). However, netkvm.inf doesn't mention it, and the driver installs just fine without it. - the balloon driver directory on virtio-win.iso contains blnsvr.exe (and .pdb) which is apparently a usermode service to report memory stats to host via balloon virtio queue. However nothing seems to automatically trigger installation of that service. Thanks, Roman. _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
