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

[Paul Durrant <xadimgnik@xxxxxxxxx>]

On 30/08/2022 10:39, Martin Harvey wrote:
> -----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.
Yes, which is why we only bump the revision to indicate that the nature 
of the 'hardware' has changed.
> > 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.
Well, we want Windows to think it is something new... that's the point.

> We have two fundamental problems (as elaborated in the doc above).
>
> - Net connection configuration settings get lost when we bump the rev ID.
Ok, and that needs investigation because the container id is hashed from 
the MAC address and *that* should not change.
> - We would like windows update to be able to update drivers in pretty much any 
> order as it find them.
And that should work because, as I said, any new dependent driver should 
remain inactive until the driver(s) it depends on are updated. I.e. the 
staging of drivers can be in any order but the PDO revisions should 
ensure that they actually *install* in the correct order.
> > 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.
Right, so there is no need for more compatibility code and I'd really 
like to keep it that way unless there is a fundamental reason why the 
current scheme will not work. To my mind compatibility in both 
directions will just complicate the code for no *good* reason.
The network settings issue is therefore what we need to understand 
first, I think.
  Paul

> 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.