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 25BCDA00C3; Fri, 15 May 2020 11:26:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 79B6C1DAA1; Fri, 15 May 2020 11:26:15 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 899EE1D9ED; Fri, 15 May 2020 11:26:13 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C07425C00D6; Fri, 15 May 2020 05:26:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 15 May 2020 05:26:12 -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= BgdUefGux7J/7iUvZ8+zUzz6NP1ScuWuYKYjUUnKH1Y=; b=N0wbeiHWsP48D4vo Lb6CKr49G31TJaQmPhIF2UoVR114kvfSEebmVtwMooOjGGiGOjL6vghfoIG+a64b jmHracArGD4hXX4LRbwixYRWBM3urxScYEMZG2mXSKfCZ791X1qT3VSggxNljG3M e2HKOXY3ToI7VTzm0ziZwtOJQLrw+CnSnZ550HP0IVXceAlTyWjBtGJps3nzGztQ tUD5foQYsoAzl3NJ255OZtrxeeLUJSmi/Th9z7wUC/MQl9vit4zcq7zJR39QdUGd +Om1dD2kRF70PV3Jhu8/yOl74l611OCpGWriF5VD9OsOt5CqUjkTZcs9Y6jexxG5 rDoOug== 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=BgdUefGux7J/7iUvZ8+zUzz6NP1ScuWuYKYjUUnKH 1Y=; b=bIAxnb/nf2vCbSec/8ExZeaONbCIPdeZBpiUmxtnyb1rWakYgLV0vcGMq 4V8Ex7hC38pQOWGTLt+2l0ptY2oRuXPNNyYfVNt7eusEWCzvFl1xeu/bnKxQG5jD ZhOcj2pOJaGDFiFimBV77mVOZtZZFH1qtf586c7hctBze6uovhG2gPbygtzZMaej lJCjPezwj0loY6S7S6FDdMqjlguJaxCUj8qb2o+Dlr3f8SMwS1TdfF3TpNqNUJyN GHRUx4z4QqVJ6ssvZdO4IihOkg8NUzAapfzxjseyHrvrjGiZi48Z2qrqHztDuN/g x/MLzIBdVB2mK52G9HPhZBR6nzShA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleekgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 6EE88306634A; Fri, 15 May 2020 05:26:10 -0400 (EDT) From: Thomas Monjalon To: David Marchand , hemant.agrawal@oss.nxp.com Cc: Ray Kinsella , dev@dpdk.org, neil.horman@tuxdriver.com, techboard@dpdk.org Date: Fri, 15 May 2020 11:26:09 +0200 Message-ID: <15584811.0ZKypZ73Fx@thomas> In-Reply-To: References: <20200512140100.26803-1-hemant.agrawal@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 01/12] common/dpaax: move internal symbols into INTERNAL section 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" 14/05/2020 19:15, Hemant Agrawal (OSS): > > On Thu, May 14, 2020 at 3:31 PM David Marchand > > wrote: > > > On Thu, May 14, 2020 at 2:39 PM Hemant Agrawal (OSS) > > > wrote: > > > > > > > > [Hemant] this is working fine for pmd_dpaa but not for pmd_dpaa2 > > > > > > > > I removed the filename_exp and introduced function based name > > > > Now the issue is the following warning SONAME changed from > > > > 'librte_pmd_dpaa2.so.20.0' to 'librte_pmd_dpaa2.so.0.200.2' > > > > > > > > The primary reason is that now pmd_dpaa2 has no symbol left for > > > > 20.0 section. > > > > Following is not helping. > > > > [suppress_file] > > > > soname_regexp = ^librte_pmd_dpaa2 so, it seems for now, the > > > > filename_exp is the only option > > > > > > That's interesting. > > > Because I wondered about this point when reviewing __rte_internal. > > > For components providing only internal symbols like components > > > providing only experimental symbols, the build framework will select a > > > soname with .0.200.x. I will remind once again that I was against this rule. Distinguishing "stable or partially stable" and "completely non-stable" libraries is an useless complication. > > > Here, your dpaa2 driver was seen as a stable library so far. > > > Moving everything to internal changes this and the build framework > > > changes the soname to non stable. > > > > Looking at a v19.11 testpmd binary: > > $ readelf -d $HOME/abi/v19.11/build-gcc-shared/usr/local/bin/dpdk-testpmd > > |grep dpaa > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_bus_dpaa.so.20.0] > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_common_dpaax.so.20.0] > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_mempool_dpaa.so.20.0] > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_pmd_dpaa.so.20.0] > > > > Changing the soname would break this. > > > > > You could keep an empty DPDK_20.0 block to avoid this and the soname > > > will be kept as is. > > [Hemant] Yes, I was thinking about it but missed to make this change while sending patch. Will do it asap. > > > > We will have to maintain such soname for all dpaa libraries until 20.11. Thank you for maintaining the soname compatibility in v7. Now the question is: what to do in v20.11? This question will have to be voted in the Technical Board which voted the "pure experimental" versioning rule. We have 3 options: a) "Pure internal" libs are versioned as "stable" libs, while "pure experimental" libs have version 0.x. It looks inconsistent and non-sense. b) "Pure internal" libs are versioned as "pure experimental" libs: version 0.x. It makes "pure internal" libs version decreasing in 20.11. c) Forget about the different versioning scheme, i.e. increase 0.x versions to x as "stable" libs. Of course, I vote for option c.