Re: [Libguestfs] [PATCH] v2v: virtio-win: include *.dll too
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(a)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.