[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [RFC] Interface compatibility example - for comment.


  • To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Paul Durrant <xadimgnik@xxxxxxxxx>
  • Date: Fri, 16 Sep 2022 07:40:37 -0700
  • Delivery-date: Fri, 16 Sep 2022 14:40:44 +0000
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>

On 07/09/2022 05:23, Martin Harvey wrote:
This patch is an example of implementing *client-side* interface
compatibility, in addition to the existing server-side mechanism.

Two-way interface compatiblity would reduce the number of cases
where we need to increment the Device-ID, which is likely to
reduce the frequency of upgrade problems, and/or lost IP configuration.

Further details on exact compatibility and upgrade cases solved by this
pending (tests currently in progress).


As you know, I'm still opposed to this idea and this patch, while I am sure it is functional, is just a small part of what is a fundamental shift. If we decide to go down this route then we'll want to do away with the whole PDO revision scheme as it stands. It also seems inefficient to have a child just walk backwards down interface version numbers until it finds a match; we really ought to be able to have some property of the PDO indicate what interface versions are available. Then there is also the pass-thru aspect of interfaces; a child may acquire an interface from any ancestor (and potentially from a filter), which may make things more complicated. As a PoC I think I'd at least want to see a stack of XENBUS, XENVIF and XENNET being able to deal with two compatibility in several different combinations.

  Paul




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.