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