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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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

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