[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.

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.


or switch to the names passed to inf2cat in its /os parameter, i.e.


Whatever convention is chosen it needs to be followed thereafter.

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'd appreciate any thoughts or suggestions on how to proceed from that
and whether it's worth it at all.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]