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 EC6B1A05D3 for ; Wed, 22 May 2019 15:14:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E110F4C80; Wed, 22 May 2019 15:14:04 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 5CCCC4C80; Wed, 22 May 2019 15:14:03 +0200 (CEST) Received: from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com ([2606:a000:111b:405a::162e] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hTR45-0001TH-HT; Wed, 22 May 2019 09:13:58 -0400 Date: Wed, 22 May 2019 09:13:17 -0400 From: Neil Horman To: Jerin Jacob Kollanukkaran Cc: Bruce Richardson , "dev@dpdk.org" , "thomas@monjalon.net" , "stable@dpdk.org" Message-ID: <20190522131317.GB18629@hmswarspite.think-freely.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-stable] [dpdk-dev] Re: [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" On Wed, May 22, 2019 at 11:54:13AM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: Bruce Richardson > > Sent: Wednesday, May 22, 2019 4:21 PM > > To: Jerin Jacob Kollanukkaran > > Cc: Neil Horman ; dev@dpdk.org; > > thomas@monjalon.net; stable@dpdk.org > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] devtools: skip the symbol check > > when map file under drivers > > > > > > 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? > > > > > > 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? > > > > > > Context: > > > I am adding a new driver/common/octeontx2 directory and it has some > > > API which Needs to shared between drivers not to the application. For > > > me, it does not make sense to go through any ABI process in such case. > > > > > > > > Maybe not, but other drivers will have APIs designed for apps to call directly - > > some NIC drivers have them, and I suspect that rawdev drivers will need > > them a lot. Therefore, it's best to have the drivers directory scanned by our > > tooling. > > Agreed. But all of those API which called directly called from application > is starts with rte_ symbol. How about skipping the symbols which is NOT start with rte_* > example: > drivers/common/octeontx/rte_common_octeontx_version.map > drivers/common/dpaax/rte_common_dpaax_version.map > No, that won't work. If you export a function, it doesn't matter if its named rte_* or not. Its accessible from any library/application that cares to call it, and so you have a responsibility to keep it stable for those users. Currently the way we have around that is the use of the __rte_experimental tag. Adding that tag to an exported function marks it as being unstable, and while you can use it, it will generate a build time warning about its use, unless you define ALLOW_EXPERIMENTAL_API. You could use that, understanding that in-tree drivers could use it safely, as you should always be keeping the API in sync with its users, but thats not quite what you want I don't think. Another solution (allbeit a slightly risky one), would be to bifurcate your header files into a public and private version, with the private version prototyping your driver-only functions properly, and the public version aliasing them such that they generate a build time error indicating those functions aren't available for public use (you can use the gcc static_assert macro I believe). Users could circumvent it by pulling the private header out of the build, or just prototyping the functions themselves, but at that point a user is asking for trouble anyway Neil