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

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 09/26/2013 11:02 AM, 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.

Right; this was an oversight, I was just explaining how it happened.
Since it was just a name change, it is also less important than if
it was an actual ABI change.

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

No kernel currently has both drivers (since upstream never had v1),
so this isn't a problem yet. The backend will bail if the frontend
doesn't set its own feature-protocol-v2 node, so an old v1 frontend
won't end up trying to talk to a v2 backend.

I agree that having a single kernel support both v1 and v2 will end
up being a bit cumbersome. I think it was considered to be unlikely
for a single kernel to want to support both, but I don't recall the
details of that discussion.

-- 
Daniel De Graaf
National Security Agency