On Thu, 2015-10-29 at 12:53 +0300, Roman Kagan wrote: > 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.
No restrictions from MS side, OEM or SW vendor can implement they own versioning scheme. Only two rules - no zeroed fields in the driver version section (to make WHQL inf check test happy), keep driver version increasing from build to build (to simplify driver update procedure). > > 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. Not sure that it will happen soon. The reason is simple - Windows allows to install any binary as a part of driver installation procedure. It only needs to be mentioned in inf file. But then if we change and rebuild that binary - we need to regenerate cat file, re-WHQL that driver and re-submit cat file to Microsoft. Even though that the balloon service is stable enough, I wouldn't recommend making it as a part of automated balloon driver installation procedure. At least not now. Best regards, Vadim. > > Thanks, > Roman. _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
