[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |