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

[Roman Kagan]

On Fri, Jan 22, 2016 at 03:30:04PM -0500, Cole Robinson wrote:
> On 01/22/2016 01:27 PM, Roman Kagan wrote:
> > 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?

Sure, please see below.

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

Speaking of that tarball in the public SRPM -- quite possible.  E.g.
viostor for w7-x86 and 2k8-x86 are built separately, both claiming
support for Vista, 2k8, and Win7, but the tarball only contains 2k8
version both for w7 and for 2k8.

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

I'd say this is a perfectly legal scenario.  The only point is that if
you update a driver for a subset of platforms it used to support, the
new driver should only claim compatibility with that subset, and not the
original set.  Strictly speaking, the signature is sort of certifying
you did the QE for that list of platforms.  AFAIK in case of WHQL this
is very explicit: you need to submit the results of running the
certification test suite for every platform you claim supporting, and
they provide you with the signed .cat file where they retain only the
platforms for which the results were accepted.

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

That idea came to me too.  Fortunately after some digging I found useful
timestamps in there:

1) there's a timestamp right in the CertificateTrustList which is
   basically the timestamp of the catalog file

2) there are (possibly multiple) signing timestamps (either Authenticode
   or RFC3161)

I'm going to take the largest timestamp out of those contained in the
.cat file as the driver timestamp, an choose the latest out of those
matching a particular configuration.

Actually I have it mostly done, gonna polish and submit soon.  Running
it against the Fedora driver set results in the same conflict in viostor
between xp-x86 and 2k3-x86 I reported before (except that this time xp
took over 2k3).

As for RHEL ones, with this approach the leftover list is much shorter:

qxl/xp/x86/qxldd.dll
qxl/xp/x86/qxl.cat
qxl/xp/x86/qxl.sys
qxl/xp/x86/qxl.inf

i.e. this the driver which ended up not chosen for any target platform.
There are a few drivers which intersect in the supported platform list
but per previous discussion I consider it acceptable.

> For the WHQL bits maybe we can just choose the latest WHQL'd driver.

I think not only WHQL, but the approach should apply in general case.
The timestamp obtained this way represents the time of the last concious
action on the driver affecting its platform compatibility.  E.g. it
should be OK to have a WHQL-ed driver set and mix in a newer
not-yet-WHQL-ed driver for a particular platform addressing a specific
issue.

> 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' ?

Both .cat files claim xp and 2k3.  I haven't tested actual work of any
driver.

Thanks,
Roman.