From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id CA480B347 for ; Fri, 19 Sep 2014 10:52:09 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 19 Sep 2014 01:57:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,553,1406617200"; d="scan'208";a="605288211" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga002.jf.intel.com with ESMTP; 19 Sep 2014 01:57:53 -0700 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Sep 2014 09:57:51 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.112]) by IRSMSX151.ger.corp.intel.com ([169.254.4.214]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 09:57:51 +0100 From: "Richardson, Bruce" To: Neil Horman , Thomas Monjalon Thread-Topic: [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility Thread-Index: AQHP0RqmICgd4br6MUeGWGIhEyJ285wHKFkAgAAOFoCAAPU5QA== Date: Fri, 19 Sep 2014 08:57:50 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0343F3852@IRSMSX103.ger.corp.intel.com> References: <1410809031-19114-1-git-send-email-nhorman@tuxdriver.com> <2657938.GdCLzJqtVh@xps13> <20140918191401.GP20389@hmsreliant.think-freely.org> In-Reply-To: <20140918191401.GP20389@hmsreliant.think-freely.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 08:52:10 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Thursday, September 18, 2014 8:14 PM > To: Thomas Monjalon > Cc: dev@dpdk.org; Richardson, Bruce > Subject: Re: [PATCH 0/4] Add DSO symbol versioning to support backwards > compatibility >=20 > On Thu, Sep 18, 2014 at 08:23:36PM +0200, Thomas Monjalon wrote: > > Hi Neil, > > > > 2014-09-15 15:23, Neil Horman: > > > The DPDK ABI develops and changes quickly, which makes it difficult f= or > > > applications to keep up with the latest version of the library, espec= ially when > > > it (the DPDK) is built as a set of shared objects, as applications ma= y be built > > > against an older version of the library. > > > > > > To mitigate this, this patch series introduces support for library an= d symbol > > > versioning when the DPDK is built as a DSO. Specifically, it does 4 = things: > > > > > > 1) Adds initial support for library versioning. Each library now has= a version > > > map that explicitly calls out what symbols are exported to using appl= ications, > > > and assigns version(s) to them > > > > > > 2) Adds support macros so that when libraries create incompatible ABI= 's, > > > multiple versions may be supported so that applications linked agains= t older > > > DPDK releases can continue to function > > > > > > 3) Adds library soname versioning suffixes so that when ABI's must be= broken > in > > > a fashion that requires a rebuild of older applications, they will br= eak at load > > > time, rather than cause unexpected issues at run time. > > > > > > 4) Adds documentation for ABI policy, and provides space to document > deprecated > > > ABI versions, so that applications might be warned of impending chang= es. > > > > > > With these elements in place the DPDK has some support to allow for t= he > extended > > > maintenence of older API's while still allowing the freedom to develo= p new > and > > > improved API's. > > > > > > Implementing this feature will require some additional effort on the = part of > > > developers and reviewers. When reviewing patches, must be checked > against > > > existing exports to ensure that the function prototypes are not chang= ing. If > > > they are, the versioning macros must be used, and the library export = map > should > > > be updated to reflect the new version of the function. > > > > > > When data structures change, if those structures are application acce= ssible, > > > apis that accept or return instances of those data structures should = have new > > > versions created so that users of the old data structure version migh= t co- > exist > > > at the same time. > > > > Thanks for your efforts. > > But I feel this change has too many constraints for the current status = of > > the DPDK. It's probably too early to adopt such policy. > > > I think you may be misunderstanding something. What constraints do you > beleive > that this patch imposes? Note it doesn't in any way prevent changes to t= he ABI > of the DPDK, but rather gives us infrastructure to support multiple ABI > revisions at the same time, so that applications built against DPDK share= d > libraries can continue to function properly at least for some time until = we > decide to deprecate that ABI level. >=20 I view all this as a positive step. I consider backward compatibility as so= mething that should always be encouraged, and I agree with Neil that this s= hould allow us to guarantee compatibility for our customers while still hav= ing a path open to us to change things if we really need to. > This is all based on the versioning strategy outlined here: > http://www.akkadia.org/drepper/dsohowto.pdf >=20 > That may help clarify things for you. >=20 > > By the way, this versioning doesn't cover structure changes. > No, it doesn't. No link-time mechanism does so. >=20 > > How could it be managed? > Thats a subject that is open to discussion, but my initial thinking is th= at we > need to handle it on a case by case basis: >=20 > * For minor updates, where allocation of a structure is done on the heap = and > new > fields need to be added, appending them to the end of a structure and pro= viding > an initial value is sufficient. >=20 > * For major changes, where fields need to be removed, or re-arranged, mos= tly > likely the API surfaces which accept or return those structures as > inputs/outputs will need to have new versions written to accept the new v= ersion > of the structure, and internally we will have to support both formats for= a time > (according to the policy I documented, that is currently a single major > release). I.e. if you want to change struct foo, which is accepted as a > parameter for the function bar(struct foo *ptr), then for a release we wo= uld > need to create struct foo_v2 with the new format, map a new function foo_= v2 > to > the exported foo@@DPDK_1.(X+1), and internally make the foo functions > understand > both the origional and v2 versions of the structure. Then in DPDK releas= e > 1.X+2, we can remove the old version after posting a deprecation notice w= ith > version 1.(X+1) I really, really like having an official deprecation policy. The one propos= ed seems reasonable as a start point - we can always decide later whether w= e want a 1, 2 or 3 release gap between marking something as deprecated and = having it removed. /Bruce =20