Re: wrong io/tpmif.h made it into upstream Linux

[David Vrabel <david.vrabel@citrix.com>]

On 26/09/13 16:02, Jan Beulich wrote:
>>>> On 26.09.13 at 16:53, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/26/2013 10:17 AM, Jan Beulich wrote:
>>>>>> On 26.09.13 at 13:52, "Jan Beulich" <JBeulich@suse.com> 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.

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

As for the module alias, we're not going to add another tpm frontend
driver to the kernel so I don't see a problem here either.

David