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

Roman Kagan rkagan at virtuozzo.com
Mon Jan 25 19:24:54 UTC 2016


On Mon, Jan 25, 2016 at 07:34:39PM +1100, Vadim Rozenfeld wrote:
> On Fri, 2016-01-22 at 15:30 -0500, Cole Robinson wrote:
> > On 01/22/2016 01:27 PM, Roman Kagan wrote:
> > >    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?
> 
> In this case, I would go with "2k8R2 and 2k12" driver for 2k8R2.
> For me "2k8 and 2k8R2" means that the driver was initially designed
> and tested to be running on 2k8 platform, but later, at some point,
> after successful testing on 2k8R2, the build script was changed to sign
> the same binary for 2k8R2 platform as well.
> While "2k8R2 and 2k12" was initially designed and built to be running on
> 2k8R2 platform.

I thought about implementing this heuristics at first.  However, this
looked like breaking certain workflows, e.g. publishing a driver update
for an older platform without touching newer ones.

So, as I said in another mail, I'm going to stick with the approach
based on the observation that the platform compatibility in the catalog
is only modified either when it's created or when it's signed.  Both
actions are supposed to be concious human decisions and both are
timestamped within the catalog.  Therefore, when there are multiple
drivers matching a particular arch/os combo, I'll give preference to the
most recent one according to that timestamp.

Roman.




More information about the virt-tools-list mailing list