[Libguestfs] packaging virtio-win (was: Re: [PATCH] v2v: virtio-win: include *.dll too)

[Richard W.M. Jones]

On Mon, Nov 23, 2015 at 08:26:10PM +0300, Roman Kagan wrote:
> On Thu, Nov 19, 2015 at 09:45:36PM +0300, Roman Kagan wrote:
> > On Wed, Nov 18, 2015 at 11:31:17PM -0500, Li Jin wrote:
> > > > > > In any case the *.inf files don't seem to have any distinguishing
> > > > > > feature which would allow us to check this.
> >
> > Catalog files are pkcs7 containers with multi-layered nested ASN.1
> > structure
> [...]
> > So it looks like yes, there's certain data in there which can be used to
> > match it against the exact Windows version; not sure what to do with all
> > this, though.
> 
> Having given it some more thought and having discussed that with
> colleagues who do various things with the drivers, like generating
> unattended install helpers or just manually installing drivers into
> guests, I'm now of the opinion that neither libguestfs nor any other
> user of the drivers should look inside the driver files in order to
> match them against the guest OS, because it's hard for programs and
> unrealistic for humans.
> 
> I tend to believe it should be the responsibility of the driver packages
> to lay out the drivers in a directory structure that both humans and
> programs could grok easily and that wouldn't change once established; in
> a sense this would be both an API and a human interface.
> 
> If I were to lay it out I'd group the stuff by guest OS, so that for a
> particular guest a single entity -- a directory tree or a pre-created
> ISO or floppy image -- would contain all that's needed for this guest
> and nothing else.  This would allow separation of concerns, so that
> actors who bring the stuff into the guest wouldn't need to care about
> what's inside, and actors involved with its installation wouldn't need
> to know how to find the right one.

The good news is that this is what we do right now.

> E.g. from this POV the way drivers are stored in RHEL7 virtio-win
> package on the *filesystem* looks OK, the way they are stored in the
> *ISO image* in the same package doesn't.
> 
> As for naming one can stick with what's being used in that virtio-win
> rpm, i.e.
> 
> {amd64,i386}/Win{XP,2003,2008,2008R2,2012,2012R2,7,8,8.1}
>
> or switch to the names passed to inf2cat in its /os parameter, i.e.
> 
> XP_X86,Server2003_X86,...,8_X64,Server8_X64,6_3_X86,6_3_X64,Server6_3_X64
> (https://msdn.microsoft.com/en-us/library/windows/hardware/ff547089(v=vs.85).aspx)
> 
> Whatever convention is chosen it needs to be followed thereafter.

Yup - very important that once we decide what the naming convention is
going to be, we stick with it.  Moving drivers around or using ad-hoc
naming schemes causes churn in virt-v2v and probably other projects
too.

> The main problem with this proposal is that I don't know how to
> implement it: there are multiple vendors of virtio-win packages, and,
> for licensing reasons, they don't even share the source code, so it's
> unclear who could own this convention and enforce it on others.

I guess that virt-v2v will have to deal with this with more special
rules.

> I'd appreciate any thoughts or suggestions on how to proceed from that
> and whether it's worth it at all.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW