[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [win-pv-devel] more changes to PDO revision numbering

On 2015-07-15 12:17, Paul Durrant wrote:
>> -----Original Message-----
>> From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
>> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Paul Durrant
>> Sent: 15 July 2015 11:09
>> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
>> Subject: [win-pv-devel] more changes to PDO revision numbering
>> Hi,
>>   I've recently realised that the way in which PDO revisions are assigned is
>> flawed. The nested-for-loop implementation doesn't guarantee that a
>> particular revision corresponds to a particular combination of interface
>> versions as was my intention, and also the combinatorial explosion that
>> occurs whenever one interface version is incremented means we burn
>> through PDO revisions pretty rapidly.  So, I propose a change...
>>   We don't really need to have a revision for *every* possible combination of
>> interfaces. A bus driver implementing the newest  version of one interface
>> and the oldest version of another possibly would never exist since often
>> multiple interfaces may be updated by a single (series of) commit(s). I
>> therefore think that we should move to an implementation that uses a table
>> mapping a set of interface versions to a PDO revision. To do this, and
>> maintain working combinations of drivers, we will need to follow some rules
>> though:
>> 1) The last line of the table should always map the latest interface 
>> versions to
>> the highest PDO revision
>> 2) A patch should never *modify* a line in the table, only add or remove
>> (although I think we can allow that for patches within the same series)
>> 3) A line should not be removed from the table until no child driver relies 
>> on
>> binding to that PDO revision [1]. I.e. child drivers get updated to bind to 
>> the
>> latest PDO revision and *then* old revisions are retired.
> Actually there's also an implicit rule here that already applied under the 
> old scheme, but may not have been obvious:
> 4) A child driver must only use interface versions that are mapped to the PDO 
> revision to which it binds.
>   Paul
>>   Under this scheme, I think we can also drop the need to register individual
>> interface versions between drivers (i.e. the current provider/subscriber
>> scheme) since we can infer what interface versions a driver is using by
>> looking at the MatchingDeviceId value in the device software key.
>>   To get from where we are to this new scheme I also propose that we just
>> start with a single line table in each bus driver (XENBUS and XENVIF) mapping
>> the latest interface versions to the current highest PDO revision. The latest
>> versions of all child drivers are currently binding to the highest PDO 
>> revisions
>> so rule 3 is adhered to.
>>   If anyone has any thoughts on this please let me know, otherwise I will
>> make changes this Friday (July 15th).
>>     Paul
>> [1] It may be necessary to deliberately make incompatible changes and thus,
>> in such exceptional circumstances, a single series may add a new line to the
>> table and remove all existing lines but we should clearly try to avoid this
>> where possible. In this case though, patch series to update child drivers
>> should be simultaneously available and committed to the relevant
>> repositories within the smallest possible time window.
I'm all for it. The current combinatorial approach is not very
maintainable in the long run as you said.

RafaÅ WojdyÅa
Qubes Tools for Windows developer

win-pv-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.