RE: [RFC] Design changes for bidirectional interface compatibility.

[Martin Harvey <martin.harvey@xxxxxxxxxx>]

-----Original Message-----
From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
Paul Durrant

> Can you send it to the list too? I don't see a problem statement in 
> your doc. What precisely is the problem with the current mechanism? 

Problem statement, and some of the issues we are seeing mentioned here:

https://citrix.sharefile.com/d-sa7ef342dad7b46c1a06f77436f282e64


> The currently implemented use of PDO names to match available 
> interface versions was very deliberately chosen to avoid the need for 
> any child driver to maintain compatibility with an older parent.

Prima facie, This seems to be a good idea. However, the point of device ID's is 
to indicate that the H/W (or virtualised H/W, or other discrete piece of kernel 
functionality) is fundamentally the same.

> As 
> long as the rule is followed (i.e a new interface combo in the parent 
> requires that the PDO rev is bumped) there really should not be any 
> compatibility problem to fix.

You're correct that there is not currently a compatibility problem at the 
moment, it's just that by bumping revisions, and changing the H/W ID's, windows 
is not able to determine that the device that's been added to the system is 
fundamentally the same as the previous device that was in the system, just with 
some tweaks to the kernel software.

We have two fundamental problems (as elaborated in the doc above).

- Net connection configuration settings get lost when we bump the rev ID.
- We would like windows update to be able to update drivers in pretty much any 
order as it find them.

> I guess I should elaborate by saying *if* a new child driver is installed in 
> system that requires an interface
> that the parent can't provide (because it is older) then the PDO naming 
> should mean that it does not load
> (yet), and the older version of the child driver currently running in the 
> system continues to be used. 

Well, that's one way of solving the problem. The whole point of compatibility 
code is that it should be perfectly possible to get the newer driver to load in 
some "reduced functionality" mode.

This does not exclude the possibility that for interface changes which are 
bugfixes where compatibility is not possible (or reasonable), of course we can 
still bump the RevID in such cases.

My document contains a review of all the interface chances for the interfaces 
currently supported between drivers, and they are not that many or large (in 
the grand scheme of things).

I should add from a "management" perspective, we now have more people in the 
trenches here, including a couple of new developers and some excellent 
dedicated test engineers, and if we need a 2k more lines of code, and a cpl of 
guys running upgrade / downgrade / siedegrade regression tests (possibly with 
results posted to this list), then that's not a problem for us.

If you wanted us to run internally with the changes for a couple of months as 
well, just to be quite sure things will work, then that's possible too.

MH.