[Libguestfs] [PATCH] v2v: virtio-win: include *.dll too

[Vadim Rozenfeld]

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.