From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id CA480B347
 for <dev@dpdk.org>; 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" <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>, Thomas Monjalon
 <thomas.monjalon@6wind.com>
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" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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