From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 89CEDA04F6; Wed, 11 Dec 2019 16:17:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5A8B12C6A; Wed, 11 Dec 2019 16:17:57 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 341211D9E for <dev@dpdk.org>; Wed, 11 Dec 2019 16:17:56 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2019 07:17:55 -0800 X-IronPort-AV: E=Sophos;i="5.69,301,1571727600"; d="scan'208";a="203595977" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2019 07:17:52 -0800 Date: Wed, 11 Dec 2019 15:17:49 +0000 From: Bruce Richardson <bruce.richardson@intel.com> To: Thomas Monjalon <thomas@monjalon.net> Cc: Ferruh Yigit <ferruh.yigit@intel.com>, Neil Horman <nhorman@tuxdriver.com>, "Kinsella, Ray" <ray.kinsella@intel.com>, David Marchand <david.marchand@redhat.com>, Luca Boccassi <bluca@debian.org>, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Timothy Redaelli <tredaelli@redhat.com>, Kevin Traynor <ktraynor@redhat.com>, dpdk-dev <dev@dpdk.org>, "Laatz, Kevin" <kevin.laatz@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, Neil Horman <nhorman@redhat.com> Message-ID: <20191211151748.GA413@bricha3-MOBL.ger.corp.intel.com> References: <5df1a33b-b338-bde1-6834-e8b5fbe65a04@intel.com> <20191211131103.GA19627@hmswarspite.think-freely.org> <d49e8bfe-034f-90a5-e2c1-db74c50ba2e7@intel.com> <13948405.dOHl5BjGNH@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13948405.dOHl5BjGNH@xps> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Wed, Dec 11, 2019 at 04:02:16PM +0100, 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. > Note that an app linked with ABI 20.2 won't be compatible with ABI 20.1, > though the reverse works. > Which I think is fine, as it is the way most people would expect it to work.