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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: RafaÅ WojdyÅa [mailto:omeg@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: 15 July 2015 14:13
> To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: 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.
> 

Cool. That's good. Thanks,

  Paul

> --
> RafaÅ WojdyÅa
> Qubes Tools for Windows developer
> https://www.qubes-os.org/
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel