On 01/22/2016 01:27 PM, Roman Kagan wrote: > On Fri, Jan 22, 2016 at 06:05:01PM +0300, Roman Kagan wrote: >> 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. >> >> 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 >> >> - 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 the >> .inf or in the .cat or not. >> >> The virtio-win driver packages I could get my hands on all matched the >> above assumptions. >> >> [ There's no integration with the rest of the system yet as I'd like to >> sort out some issues first which may affect the logic (in a followup >> mail). ] > > Now to the issues I'd like to discuss before moving on. > > The current make-*.py scripts can probably be simplified dramatically > with this new logic. However they contain a fair amount of consistency > checks which I'd like to maintain. Besides, I'd like to figure out > what's on input and what's the desired output of the process. > > Here's the way I thought of using the submitted scripts (in bash for > simplicity of explanation): > > ==== > set -e > > wrkdir=$(mktemp -d windrvXXXXXX) > dstdir=$wrkdir/virtio-win > > # fetch the drivers (in real life will come from a windows build machine > # directly) > curl https://fedorapeople.org/groups/virt/virtio-win/repo/srpms/virtio-win-0.1.112-1.src.rpm | > rpm2cpio | > cpio -i --to-stdout virtio-win-\*-bin-for-rpm.tar.gz | > tar -xzf - -C $wrkdir > > srcdir=$(echo $wrkdir/*) > > rm -fr $srcdir/{*.vfd,vfddrivers} > > # get rid of duplicates (already done for the package in the above srpm > # but will be needed in general) > hardlink $srcdir > > # lay out the drivers hardlinking them to the source > util/cpdrivers.py -m link $srcdir $dstdir/drivers > > # indentify files left behind > find $srcdir -type f -links +1 -exec rm \{\} \; > echo "unpackaged files:" > find $srcdir -type f -printf '%P\n' > # do something if any is found > : ... > > # add license, qga, etc. to $dstdir > : ... > > # create iso image with everything > mkisofs -o $dstdir/virtio-win.iso -J $dstdir/{drivers,qga} > > # create per-arch/os floppies with basic drivers > for archdir in $dstdir/drivers/*; do > arch=${archdir##*/} > for osdir in $archdir/*; do > os=${osdir##*/} > > img=$dstdir/${arch}_{os}.vfd > truncate -s 2880k $img > mkdosfs $img > mcopy -i $img $osdir/{netkvm,vioscsi,viostor}/*.{inf,cat,sys} :: > # locate and copy txtsetup.oem (dunno if necessary) > : ... > done > done > > # $dstdir is to be found as /usr/share/virtio-win in the resulting rpm > ====== > > The discussion items: > > 1) is it a sensible thing to do in general, with these inputs and > outputs? > Yes the above sounds reasonable. > 2) the search for unpackaged files yields some. E.g. the srpm used > above gives > > viostor/xp/x86/viostor.sys > viostor/xp/x86/viostor.inf > viostor/xp/x86/viostor.pdb > viostor/xp/x86/viostor.cat > > meaning that there's another viostor driver in the tree which claims > xp-x86 support. Indeed, 2k3-x86 driver, being different from xp-x86, > claims compatibility with both xp and 2k3, and happens to take over. > > There are even more leftovers in the latest RHEL package, that is, > there are more drivers intersecting in the supported OS lists. > Can you list the RHEL conflicts? > And I'm afraid this may be a legitimate situation. Assume a driver > is signed for, say, 2k8 and 2k8R2, and then a newer version is built > and signed for 2k8R2 and 2k12. The script will make arbitrary choice > of the driver for 2k8R2. Any suggestion on what to do with this? > Hmm. This is a bit weird. Probably some combination of: 1) plain old packaging error. some wires got crossed and we never updated the xp driver to share with 2k3 or something similar 2) qe/supportability concerns. maybe the newer 2k3 build was done to fix a 2k3 specific driver, so we only updated 2k3 in the tree to avoid having to re-QE the xp driver as well. or something in that ballpark. Maybe vadim knows more, CCd If #2 is involved I'd rather we work around that some other way: either re-QE the driver, or only WHQL it for the windows version we care about (not sure if that's possible). Having to track this statically is a pain As for figuring it out in your script, does the .cat file have a date in it? For the WHQL bits maybe we can just choose the latest WHQL'd driver. For the non-WHQL bits, do the driver files end up interchangable? Or is the xp driver 'xp only' but the 2k3 driver is '2k3 + xp' ? - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
