From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 3BBDBAD81 for ; Tue, 3 Feb 2015 21:20:37 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YIjxY-0002CL-NL; Tue, 03 Feb 2015 15:20:35 -0500 Date: Tue, 3 Feb 2015 15:20:31 -0500 From: Neil Horman To: Thomas Monjalon Message-ID: <20150203202031.GE29720@hmsreliant.think-freely.org> References: <1419109299-9603-1-git-send-email-nhorman@tuxdriver.com> <4840704.t0YkBNyamY@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4840704.t0YkBNyamY@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Add DSO symbol versioning to supportbackwards 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: Tue, 03 Feb 2015 20:20:37 -0000 On Tue, Feb 03, 2015 at 05:01:51PM +0100, Thomas Monjalon wrote: > 2014-12-20 16:01, Neil Horman: > > GI: [PATCH 1/4] compat: Add infrastructure to support symbol versioninBI > > develops and changes quickly, which makes it difficult for > > applications to keep up with the latest version of the library, especially when > > it (the DPDK) is built as a set of shared objects, as applications may be built > > against an older version of the library. > > > > To mitigate this, this patch series introduces support for library and 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 applications, > > 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 against 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 break 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 changes. > > > > With these elements in place the DPDK has some support to allow for the extended > > maintenence of older API's while still allowing the freedom to develop 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 changing. 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 accessible, > > apis that accept or return instances of those data structures should have new > > versions created so that users of the old data structure version might co-exist > > at the same time. > > > > Note it was requested that this series be delayed until DPDK 2.0, so this is a > > repost, now that DPDK 1.8 has been tagged. > > > > Signed-off-by: Neil Horman > > CC: Thomas Monjalon > > CC: "Richardson, Bruce" > > CC: "Robert Love" > > After updating to version 2.0, and sorting symbol lists, > Applied > > It's probably an important change which makes 2.0 number meaningful. > Thanks > -- > Thomas > Thank you Thomas! Just as a heads up, there may be some inconsistencies resulting from patches that you merged between the time of my last repost and the time of this merge. They'll be easy to fix as they will just amount to symbol additions/removals from the various version map file. So please cc me on any sucpicious build breaks in the next few days when building shared objects, and I'll fix them up ASAP. Neil