From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3E7AFA04F6; Wed, 11 Dec 2019 16:59:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 163FF2C6A; Wed, 11 Dec 2019 16:59:30 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1FCD31D9E for ; Wed, 11 Dec 2019 16:59:27 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2019 07:55:47 -0800 X-IronPort-AV: E=Sophos;i="5.69,301,1571727600"; d="scan'208";a="207734305" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2019 07:55:43 -0800 Date: Wed, 11 Dec 2019 15:55:40 +0000 From: Bruce Richardson To: Ferruh Yigit Cc: Thomas Monjalon , Neil Horman , "Kinsella, Ray" , David Marchand , Luca Boccassi , Christian Ehrhardt , Timothy Redaelli , Kevin Traynor , dpdk-dev , "Laatz, Kevin" , Andrew Rybchenko , Neil Horman Message-ID: <20191211155540.GC413@bricha3-MOBL.ger.corp.intel.com> References: <5df1a33b-b338-bde1-6834-e8b5fbe65a04@intel.com> <20191211131103.GA19627@hmswarspite.think-freely.org> <13948405.dOHl5BjGNH@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Subject: Re: [dpdk-dev] How to manage new APIs added after major ABI release? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Dec 11, 2019 at 03:46:10PM +0000, Ferruh Yigit wrote: > On 12/11/2019 3:02 PM, Thomas Monjalon wrote: > > 11/12/2019 14:30, Ferruh Yigit: > >> On 12/11/2019 1:11 PM, Neil Horman wrote: > >>> On Tue, Dec 10, 2019 at 11:56:28AM +0000, Ferruh Yigit wrote: > >>>> Hi, > >>>> > >>>> With new process, the major ABI releases will be compatible until it is > >>>> deprecated (until next LTS for now), > >>>> like current ABI version is 20 in DPDK_19.11 and DPDK versions until DPDK_20.11 > >>>> will be ABI compatible with this version. > >>>> > >>>> But if we introduce a new API after major ABI, say in 20.02 release, are we > >>>> allowed to break the ABI for that API before DPDK_20.11? > >>>> > >>>> If we allow it break, following problem will be observed: > >>>> Assume an application using .so.20.1 library, and using the new API introduced > >>>> in 20.02, lets say foo(), > >>>> but when application switches to .so.20.2 (released via DPDK_20.05), application > >>>> will fail because of ABI breakage in foo(). > >>>> > >>>> I think it is fair that application expects forward compatibility in minor > >>>> versions of a shared library. > >>>> Like if application linked against .so.20.2, fair to expect .so.20.3, .so.20.4 > >>>> etc will work fine. I think currently only .so.20.0 is fully forward compatible. > >>>> > >>>> If we all agree on this, we may need to tweak the process a little, but before > >>>> diving into implementation details, I would like to be sure we are in same page. > >>>> > >>> Yes, I agree with the assertion. Once an ABI is fixed, it must be compatible > >>> with all future minor releases subsequent to the fixing of that ABI, until the > >>> next major update. That is to say, once you release ABI_20, all minor updates > >>> 20.01, 20.02, etc must be compatible with ABI_20 until such time as ABI_21 is > >>> released. > >> > >> There is a slight difference. All minor versions already compatible with ABI_20, > >> like: 20.01, 20.02, 20.03 are ABI compatible with 20.0 (which defines ABI_20). > >> > >> Question is if 20.03 should be compatible with 20.02? > >> > >> This can happen if a new API is introduced in 20.2 and ABI has broken for that > >> API in 20.3, so an ABI compatibility issue created between 20.03 & 20.02, > >> meanwhile both are compatible with ABI_20. > >> > >> I can see two options: > >> a) New APIs are introduced only when we switch to new major ABI version. But if > >> we switch to longer (2 years) ABI compatibility, I think this is unacceptable to > >> wait up to two years to have (non experimental) APIs. > > > > I agree we should allow to add a new stable API in the middle of an ABI lifecycle. > > > >> b) APIs added in minor version will be part of ABI_20 after that point and same > >> rules will apply to them. Like if and API has introduced in 20.2, it is not > >> allowed to be broken until next major ABI version. > > > > Yes I think it is compliant with the agreed policy. > > So I think two minor changes are required in the process to reflect this, > 1) In ABI policy [1], it mentions in minor release both ABI_20 and ABI_21 can > exist together, also in graph it says for minor versions: > "v21 symbols are added and v20 symbols are modified, support for v20 ABI continues." > I am not sure if we can call the symbols added in minor versions as v21 ABI, > because it implies ABI compatibility is not required for them. > > 2) In ABI versioning [2], documented as .map files will have 'DPDK_20' and > 'DPDK_21' blocks. > But instead, I think they should have 'DPDK_20.0', 'DPDK_20.1', ... blocks, and > when major ABI version changed they all can be flattened to 'DPDK_21.0'. > For example we can't do ABI versioning between 20.2 & 20.3 if we don't have > these blocks. > Current block names in .map files are already defined as 'DPDK_20.0', what we > need to do is update the document to use 'DPDK_20.x' for the symbols added in > minor version and follow that process. > What do we really gain from making such a change from the policy? I think it will work fine as-is, with putting all new symbols in the DPDK_21 section. Whatever way you look at it, the functions will be forward but not backward compatible, which is all that really matters. /Bruce