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.8...)
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