From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: wrong io/tpmif.h made it into upstream Linux Date: Thu, 26 Sep 2013 12:25:40 -0400 Message-ID: <52446004.3030903@tycho.nsa.gov> 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"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VPENv-0006ho-Vm for xen-devel@lists.xenproject.org; Thu, 26 Sep 2013 16:25:48 +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: xen-devel List-Id: xen-devel@lists.xenproject.org On 09/26/2013 11:02 AM, 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. 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