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

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



> -----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.
> 
> _______________________________________________
> win-pv-devel mailing list
> win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel


 


Rackspace

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