From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: wrong io/tpmif.h made it into upstream Linux Date: Thu, 26 Sep 2013 16:59:05 +0100 Message-ID: <524459C9.3020002@citrix.com> References: <52443C0C02000078000F6CF0@nat28.tlf.novell.com> <52445E2602000078000F6ECC@nat28.tlf.novell.com> <52444A6F.2070006@tycho.nsa.gov> <5244689302000078000F7008@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VPDyA-0004Bq-An for xen-devel@lists.xenproject.org; Thu, 26 Sep 2013 15:59:10 +0000 In-Reply-To: <5244689302000078000F7008@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Matthew Fioravante , xen-devel , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On 26/09/13 16:02, Jan Beulich wrote: >>>> On 26.09.13 at 16:53, Daniel De Graaf wrote: >> On 09/26/2013 10:17 AM, Jan Beulich wrote: >>>>>> On 26.09.13 at 13:52, "Jan Beulich" 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