[Libguestfs] [PATCH] v2v: virtio-win: include *.dll too
Vadim Rozenfeld
vrozenfe at redhat.com
Fri Oct 30 05:28:10 UTC 2015
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 <rjones at redhat.com> 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.
More information about the Libguestfs
mailing list