[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] wrong io/tpmif.h made it into upstream Linux
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |