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 43301A0093; Mon, 18 May 2020 12:46:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1744B1D414; Mon, 18 May 2020 12:46:16 +0200 (CEST) Received: from wnew1-smtp.messagingengine.com (wnew1-smtp.messagingengine.com [64.147.123.26]) by dpdk.org (Postfix) with ESMTP id F3ECD1D14F; Mon, 18 May 2020 12:46:14 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 1EAD5776; Mon, 18 May 2020 06:46:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 18 May 2020 06:46:13 -0400 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=fm1; bh= Gr+i5vBgVCg9x0Gq1QOj8Cox0CzadoavOW7YDpcbTQY=; b=O5Stqrub69JxMIl+ Eb9pc8tleisBAZpwt3iWFK+kIHgKUzPlQnM46KtrgPHfNNKujINTKvQ8baX8mjyV MKoSFAWlfAETGb2k4bmcLdoKyqyCn1Hpa9cvvwMeWJh0yzgYE5UiI3o1fXHot5rE xCAQlWZdGDxfwXWP4A7IDAdSue7TrOcJSyq6CPvIoNbhyw8BgDt0esx+Go3ezBUu A8xXZ/Kj4oG1oTGVxU+cr0pGdCBdHLDtKhKOIeK5pAa5UoqiH7QVRGDVV1RBCzVh QfaIWKk5PKzx14tCBqyHHYZt0NLWGx1S+AGDm+LwxHszWIQmI7fA9bRhgYwxe18e j+vzmQ== 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=fm2; bh=Gr+i5vBgVCg9x0Gq1QOj8Cox0CzadoavOW7YDpcbT QY=; b=unBA4n360CPDx0yKiJZdl+6XWv0WFoip2ivwzVXLAMQXfmYBk3D1oxPNm 6B901ytEZ4yl9y9BWats+O1jeCffb69f3/EQaGqoi/AUDwlBaS7vwSbxM8AtaOPo pn0pE4knLhYmocpPco6Q3MgixouGQRjivnmt3P0BvNWJCDUM/xj7qXNLNtgCCtI/ mAe22Ws9GyWDxKBWkjGdhI0teK59oWuDNyy1Acitc3uZopJ9Dhsy7xHY05nIJnpK 5Jz4e7gLCuEZUuIk8QSgI9L/tuCJzEG8plK/Tr+4pZIQ5KccVAWZvo3pRidqDChN 9l5UY0wUOmbHHGJjRQkdNSjQcglTA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddthedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 3AE9930663F1; Mon, 18 May 2020 06:46:10 -0400 (EDT) From: Thomas Monjalon To: "Yigit, Ferruh" , Ray Kinsella , "Dumitrescu, Cristian" Cc: Neil Horman , Eelco Chaudron , "dev@dpdk.org" , David Marchand , "stable@dpdk.org" , Luca Boccassi , "Richardson, Bruce" , "Stokes, Ian" , Andrzej Ostruszka Date: Mon, 18 May 2020 12:46:08 +0200 Message-ID: <69122822.RN2Pgac3cq@thomas> In-Reply-To: References: <20200513121149.2283385-1-ferruh.yigit@intel.com> <3888163.3T5rpR7ggn@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4] meter: provide experimental alias of API for old apps 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" 18/05/2020 11:30, Ray Kinsella: > On 18/05/2020 10:22, Thomas Monjalon wrote: > > 18/05/2020 08:29, Ray Kinsella: > >> On 17/05/2020 20:52, Dumitrescu, Cristian wrote: > >>> From: Yigit, Ferruh > >>>> > >>>> On v20.02 some meter APIs have been matured and symbols moved from > >>>> EXPERIMENTAL to DPDK_20.0.1 block. > >>>> > >>>> This can break the applications that were using these mentioned APIs on > >>>> v19.11. Although there is no modification on the APIs and the action is > >>>> positive and matures the APIs, the affect can be negative to > >>>> applications. > >>>> > >>>> Since experimental APIs can change or go away without notice as part of > >>>> contract, to prevent this negative affect that may occur by maturing > >>>> experimental API, a process update already suggested, which enables > >>>> aliasing without forcing it: > >>>> https://patches.dpdk.org/patch/65863/ > >>>> > >>> > >>> Personally, I am not convinced this is really needed. > >>> > >>> Are there any users asking for this? > >> > >> As it happens it is all breaking our abi regression test suite. > >> One of the things we do is to run the unit tests binary from v19.11 against the latest release. > >> > >>> Is there any other library where this is also applied, or is librte_meter the only library? > >> > >> librte_meter is the only example AFAIK. > >> But then we only have one example of needing symbol versioning also at the moment (Cryptodev). > >> > >> This is going to happen with experimental symbols that have been around a while, > >> that have become used in applications. It is a non-mandatory tool a maintainer can use > >> to preserve abi compatibility. > > > > If you want to maintain ABI compatibility of experimental symbols, > > it IS a mandatory tool. > > You cannot enforce your "ABI regression test suite" and at the same time > > say it is "non-mandatory". > > > > The real question here is to know whether we want to maintain compatibility > > of experimental symbols. We said no. Then we said we can. > > The main concern is the message clarity in my opinion. > > > > There is complete clarity, there is no obligation. > Our lack of obligation around experimental, is upfront in the policy is upfront in the policy. > > "Libraries or APIs marked as experimental may change without constraint, as they are not considered part of an ABI version. Experimental libraries have the major ABI version 0." > > Later we give the _option_ without obligation to add an alias to experimental.pls see the v6. > > + - In situations in which an ``experimental`` symbol has been stable for some > + time. When promoting the symbol to become part of the next ABI version, the > + maintainer may choose to provide an alias to the ``experimental`` tag, so > + as not to break consuming applications. > > So it is something a Maintainer, _may_ choose to do. > I use the word, "may" not "will" as there is no obligation's associated with experimental. OK Ray, this is my understanding as well. The only difficult part to understand is when claiming "it is all breaking our abi regression test suite" to justify the choice. As the maintainer (Cristian) says he does not like this change, it means the regression test suite should skip this case, right?