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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.13 at 17:59, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 26/09/13 16:02, Jan Beulich wrote:
>>>>> 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.
> 
> So long as the ABI itself is consistent I don't see any real problem
> with there being differences in structure/field names.

But it's confusing at the very least.

>>>> 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.
> 
> Surely there isn't a problem here?  The v2 frontend won't connect to a
> v1 backend because the v1 backend doesn't report feature-protocol-v2, right?

But the other way round it would happen.

Jan


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