From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: Add DSO symbol versioning to supportbackwards compatibility Date: Tue, 03 Feb 2015 17:01:51 +0100 Message-ID: <4840704.t0YkBNyamY@xps13> References: <1419109299-9603-1-git-send-email-nhorman@tuxdriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Neil Horman Return-path: In-Reply-To: <1419109299-9603-1-git-send-email-nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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