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 DC94819F5 for ; Fri, 9 Jan 2015 13:35:15 +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 1Y9YmS-0008P9-4h; Fri, 09 Jan 2015 07:35:13 -0500 Date: Fri, 9 Jan 2015 07:35:07 -0500 From: Neil Horman To: dev@dpdk.org Message-ID: <20150109123507.GA26082@hmsreliant.think-freely.org> References: <1419109299-9603-1-git-send-email-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1419109299-9603-1-git-send-email-nhorman@tuxdriver.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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: Fri, 09 Jan 2015 12:35:16 -0000 On Sat, Dec 20, 2014 at 04:01:35PM -0500, Neil Horman wrote: > 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" > > Ping Thomas....