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 74736A04F6; Wed, 11 Dec 2019 16:02:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B475134EF; Wed, 11 Dec 2019 16:02:26 +0100 (CET) Received: from wnew1-smtp.messagingengine.com (wnew1-smtp.messagingengine.com [64.147.123.26]) by dpdk.org (Postfix) with ESMTP id 8F9DC2C6A for ; Wed, 11 Dec 2019 16:02:25 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id C82279D7; Wed, 11 Dec 2019 10:02:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 11 Dec 2019 10:02:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=C+7vuhTzoYMUIEy+vVaBeb1PQYh956YwxxVrJyZFoGA=; b=JpH43eicZ3aC 0az062o1C8NBd8ToaXZwcy4wMA4sUwxM0YfGeoaVD9O8LNu3CRcylP8h5FLRlTcd Zl6kcHCV3Ih/JE2w4pm1BVh3BC8M5aqPy61Cn8jfQD/dCbciF7YaxgXpGDYfucaX ArreDdVgOZpLnfQVlq6a+amDOK4DBEE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=C+7vuhTzoYMUIEy+vVaBeb1PQYh956YwxxVrJyZFo GA=; b=eyzhHdHJxuegX5XETOKRvxTPJI1krzNKnqyJOCnNCPUPzdkcoH1p2cDHJ 8V1YQDBpFCeSKiHXUQOjlLrRImv2Ws2WAFMdgTuIOMZIZBgxfNpcZxe7l1kAdLF8 fI/MJ95QSOUIYWyoGCv/N7kd0fKI2R5vr2FFpqgS2CXeBrwt8+05OmmrWH8zgEAG AbE22uwZFPzH2VDbp0RSgRAMLe5+usEFrOIO5N27VnVcG7JhRDUwO9Sbvxg0iNfK Mvo6yw+SxmHGXZRWKiDVuvTjIRnM3/Vo2+V7rM0KOGkqDBLrc0mJZLu0PpELOpBj uLfGFtdpY56X5/bsKslUGUyuQS+KA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudelhedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F58F80060; Wed, 11 Dec 2019 10:02:18 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: Neil Horman , "Kinsella, Ray" , David Marchand , Luca Boccassi , Christian Ehrhardt , Timothy Redaelli , Kevin Traynor , dpdk-dev , Bruce Richardson , "Laatz, Kevin" , Andrew Rybchenko , Neil Horman Date: Wed, 11 Dec 2019 16:02:16 +0100 Message-ID: <13948405.dOHl5BjGNH@xps> In-Reply-To: References: <5df1a33b-b338-bde1-6834-e8b5fbe65a04@intel.com> <20191211131103.GA19627@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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.