From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D1F06A05D3 for ; Wed, 22 May 2019 16:12:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A93E710BD; Wed, 22 May 2019 16:12:45 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id C85BF10BD; Wed, 22 May 2019 16:12:44 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4E39121EAE; Wed, 22 May 2019 10:12:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 22 May 2019 10:12:44 -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=mesmtp; bh=+WAYYR229j8PisSUa+pXNNWiuVoUwZk7UfZcQng0xBs=; b=ZybGjgStevx6 AGG8Gess9wbHE7NO7W/jTD/JjB1RDqZHm7S+DbwutiYF3WmXeWTzwfKT9zUHJzmA 7WwQKaL5RW6h6syr2a24r/8cDeyyS1d93BrI5aVxvoTVqdG/OyaglJ+86fdr1A5y xhOX4+864Ttowy8CXdZZWC56taUXtDw= 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=+WAYYR229j8PisSUa+pXNNWiuVoUwZk7UfZcQng0x Bs=; b=zQVCJLQHl36ZAsMlA2a6b/tHr3axlDSrDLbOE18TjTeOZJXcaFuSXw6eJ HsmhEz9Me8/vWn1Oz+JamemesqWzjnbsKYO5rQxa8hLArYumeWS0mq5AlwWpttAy r3TU9zq8i1BZTFhDB1Fc0k7aKCwdyB/8T8MJ9pjpsDcYqZdthz3DZgZI6AgUAlaS D6DR7pUzCXVcRfx+mUZob+DL0Ppk6URBQ2K+bdB6hJd38XwQCfHI8EOYfUR8PglY xWfWJkkdLSU0Ol6lekIXDu1tgeTXBitfINtJ5SN3OPu5QGb5c9Vl6as/lkw/oLOz iVMFNYBGtL1aJdzvUhfENm/9dmVDw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudduvddgjeefucetufdoteggodetrfdotf 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 10A9E38008A; Wed, 22 May 2019 10:12:42 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Kollanukkaran Cc: Neil Horman , "dev@dpdk.org" , "stable@dpdk.org" Date: Wed, 22 May 2019 16:12:40 +0200 Message-ID: <2338315.GuTbrZZCDE@xps> In-Reply-To: <20190522134056.GC18629@hmswarspite.think-freely.org> References: <20190522134056.GC18629@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] devtools: skip the symbol check when map file under drivers X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 22/05/2019 15:40, Neil Horman: > On Wed, May 22, 2019 at 01:12:34PM +0000, Jerin Jacob Kollanukkaran wrote: > > From: Neil Horman > > > On Wed, May 22, 2019 at 03:05:54AM +0000, Jerin Jacob Kollanukkaran > > > wrote: > > > > From: Neil Horman > > > > > On Wed, May 22, 2019 at 01:26:28AM +0530, jerinj@marvell.com wrote: > > > > > > From: Jerin Jacob > > > > > > > > > > > > Drivers do not have ABI. > > > > > > Skip the symbol check if map file under drivers directory. > > > > > > > > > > > > Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol > > > > > > addition") > > > > > > > > > > > > Cc: stable@dpdk.org > > > > > > Cc: Neil Horman > > > > > > > > > > > Sorry, but I'm not ok with this, because many of our DPDK PMDs have > > > > > functions that get exported which are meant to be called by > > > > > applications directly. The > > > > > > > > OK. Just to update my knowledge, Should those API needs to go through > > > > ABI/API depreciation process? > > > > > > > Yes, they definately should, they are API's just as any other in the core DPDK > > > library. > > > > OK > > > > > > > > > > > Actually, I am concerned about the APIs, which is called between > > > > drviers not the application. For example, > > > > drivers/common/dpaax/rte_common_dpaax_version.map > > > > > > > > it is not interface to application rather it is for intra driver case. > > > > I think, I can change my logic to Skip the symbols which NOT starting with > > > rte_. > > > > Agree? > > > > > > > No, Thats just one case, and if those calls are between drivers, so be it, but > > > those still need to be stable, and we have other examples (like the bonding > > > or dummy driver), which have additional APIs that are explicitly meant to be > > > used by an application. > > > > There is no disagreement on the API that exposed to application. > > I am concerned with internal driver APIs. For example, I am getting following warning > > > > ERROR: symbol otx2_mbox_alloc_msg_rsp is added in the DPDK_19.05 section, but is expected to be added in the EXPERIMENTAL section of the version map > > > Thats a warning about the fact that you added an API call in a versioned section > of a library instead of the Experimental section, thats part of our policy. New > APIs need to go through the experimental tag first. > > I understand what you are saying about driver only apis, and I mentioned that in > my other email farther down the thread. The problem is that "driver only apis" > are currently just a conceptual thing for us to discuss. They're still, > practially speaking, API's that any downstream user can access and become > dependent on, which we need to manage, either by keeping the API stable, so it > stays usable for all callers, or by developing a way to mark driver only API's > as such. I proposed a method that you might use to do the latter in my other email. > > > This API suppose to be called only a octeontx2 network driver from octeontx2 common driver > > i.e application should not expect any stability on intra driver functions or it does not meant to > > be used by application. > > > Ok, but again, your assertion is that its driver to driver only, but in > practicaility, that assertion is irrelevant. Those symbols are still exposed > for general use, and weather or not you say they aren't part of the ABI, the > fact of the matter is, there is no way to tell the difference from a linked > object standpoint. Instead of hobbling the tool to just not scan anything, you > need to find a way to differentiate these symbols, so that you can enforce your > assertion that there are restrictions on where these APIs are called from. > > Neil > > > Thomas, > > Any thought on this? As Neil said, we need to differentiate the internal APIs. We already have this issue in a number of places like EAL, or ethdev, and it was poorly addressed with some comments like "@internal". Practically I don't care about stability of these internal functions, but I agree that it creates a mess in the tooling and confuse users.