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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list