[virt-tools-list] [PATCH RFC virtio-win-pkg-scripts 0/2] helpers to standardize driver directory layout

[Roman Kagan]

On Wed, Jan 20, 2016 at 06:33:26PM -0500, Cole Robinson wrote:
> On 01/18/2016 09:15 AM, Roman Kagan wrote:
> > As was discussed some time ago on libguestfs ML
> > (http://thread.gmane.org/gmane.comp.emulators.guestfs/8341/focus=8576)
> > there is a need in a tool that would lay out the Windows guest drivers
> > on a filesystem by Windows flavor and architecture in a way that is
> > 
> > - easy to consume by both humans and programs
> > - dependable in the long term
> > 
> > This patch series brings in the scripts to do this.
> > 
> > The scripts are based on the idea that the most actual information about
> > the suitability of a driver for a particular flavor / architecture is
> > contained in the driver's catalog file (in particular, the process of
> > ISV or WHQL siging may affect it).
> > 
> > Since the catalog files are DER-encoded ASN.1 structures the first patch
> > introduces a module to extract relevant information from a .cat file
> > using PyASN1 library.
> > 
> 
> Sounds good. Have you tested this against WHQL cat files?

Yes.  And seem to have found a couple of bugs in there ;)

> Or just those chipped with the public/fedora drivers?

With those too.

> > The second patch introduces a script that lays out the drivers by
> > arch/flavor.
> > It assumes that
> > 
> > - every driver for a particular arch/flavor is contained in a separate
> >   directory
> > 
> 
> This is correct... but in fedora/RHEL we do use hard links to share the same
> file across multiple directories, since some drivers are WHQL signed for
> multiple windows versions, so keeping a full copy is redundant. I don't think
> that matters here though.

The copying script has four modes: full copy, file hardlinks, file
symlinks (including relative), directory symlinks.  E.g. if you prepare
stuff for building a cd or a floppy image you'll probably want full
copy; if lay out things in an rpm you'd rather use one of the linking
modes.

> (TBH it's difficult to keep all the variables here in my head, so I may be
> wrong about things... but once there's more complete patches I'll play with
> them and verify my assumptions)

Well both scripts are callable so you can play right now.

E.g. to dump relevant fields from a .cat file:

# python util/parsecat.py some/where/smth.cat

To see what would be done with the drivers:

# python util/cpdrivers.py -n -m symlink contents/of/virtio-win/iso \
  destination/path

> > - the directory contains a single .inf file; the basename of the file is
> >   taken as the name of the package
> > 
> > - the .cat file for the package is in the same directory and has the
> >   same basename as the .inf
> > 
> > - all the files contained in that directory are associated with the
> >   driver and go together with it no matter if they are listed in .inf or
> >   .cat or not.
> > 
> 
> Yes I believe these assumptions are correct.
> 
> 
> > The virtio-win driver packages I could get my hands on all matched the
> > above assumptions.
> > 
> 
> All in all this sounds good. The code looks fine modulo some style nits that
> aren't worth harping over, they can be cleaned up later.

No prob fixing the style things too, as I'll probably need to resubmit
the series anyway with proper integration into the rest of the system.

Thanks,
Roman.