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