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

[Cole Robinson]

On 01/21/2016 04:47 AM, Roman Kagan wrote:
> 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.
> 

Gotchya, though ISO can handle hardlinks FYI.

>> (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
> 

Indeed, I'll try to carve out some time.

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

- Switch to argparse (from optparse)
- Run pep8 over the code

That should turn up some things

Thanks,
Cole