Re: [Xen-devel] wrong io/tpmif.h made it into upstream Linux

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.13 at 16:53, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 09/26/2013 10:17 AM, Jan Beulich wrote:
>>>>> On 26.09.13 at 13:52, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>> in the course of reviewing the hypervisor side of this (i.e. the
>>> canonical copy of the header) I had requested some renames,
>>> and they had also been carried out there. Why did this not get
>>> adjusted _before_ hitting Linus'es tree? It's particularly strange
>>> because this can't be because different people were doing one
>>> side and the other...
> 
> This was a mistake on my part. When these changes were made, the header
> for Linux had already been split off in order to remove unnecessary
> typedefs and extra structure definitions in the Xen header. The v4 patch
> for Linux was just based on the v3 Linux patch, and the patch for Xen
> making these changes (which you wrote and I just Acked) didn't mention
> needing to make a parallel change the Linux patch, so I never made the
> changes.

To me it goes without saying that if the master copy changes,
clones should take care to propagate them properly.

>> Additionally using xen:vtpm as module alias collides with the v1
>> implementation too afaict. Was avoiding conflicts with the old
>> interface also not being considered here at all? Afaict the
>> backend also would need to announce itself differently from
>> the v1 one to xenbus...
> 
> The feature-protcol-v2 node was created to allow distinguishing the new
> interface from the old one. Naming the xenbus node "vtpm2" was
> considered for a while, but I believe it was considered unnecessary with
> the introduction of that node.
> 
> It should be possible for the the driver to choose which shared page
> format to use based on the feature node, if a driver supporting both
> protocols were needed.

But that leaves out the existing (non-upstream) v1 drivers that
won't know to look for that new node. A protocol change should
never claim to be the same version protocol as its predecessor.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel