[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 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. >>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |