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 BEED7A05D3 for ; Wed, 22 May 2019 17:39:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9D8254CAB; Wed, 22 May 2019 17:39:32 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id B7059A69; Wed, 22 May 2019 17:39:30 +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 1hTTKp-0002il-EO; Wed, 22 May 2019 11:39:23 -0400 Date: Wed, 22 May 2019 11:38:43 -0400 From: Neil Horman To: Jerin Jacob Kollanukkaran Cc: Bruce Richardson , "dev@dpdk.org" , "thomas@monjalon.net" , "stable@dpdk.org" Message-ID: <20190522153843.GF18629@hmswarspite.think-freely.org> References: <20190522141116.GD18629@hmswarspite.think-freely.org> 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-dev] [EXT] Re: Re: [PATCH] devtools: skip the symbol check when map file under drivers 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" On Wed, May 22, 2019 at 02:25:14PM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: Neil Horman > > Sent: Wednesday, May 22, 2019 7:41 PM > > To: Jerin Jacob Kollanukkaran > > Cc: Bruce Richardson ; dev@dpdk.org; > > thomas@monjalon.net; stable@dpdk.org > > Subject: [EXT] Re: [dpdk-dev] Re: [PATCH] devtools: skip the symbol check > > when map file under drivers > > > > External Email > > > > ---------------------------------------------------------------------- > > On Wed, May 22, 2019 at 01:41:03PM +0000, Jerin Jacob Kollanukkaran wrote: > > > > -----Original Message----- > > > > From: Neil Horman > > > > Sent: Wednesday, May 22, 2019 6:43 PM > > > > To: Jerin Jacob Kollanukkaran > > > > Cc: Bruce Richardson ; dev@dpdk.org; > > > > thomas@monjalon.net; stable@dpdk.org > > > > Subject: [EXT] Re: [dpdk-dev] Re: [PATCH] devtools: skip the symbol > > > > check when map file under drivers > > > > > > > > External Email > > > > > > > > -------------------------------------------------------------------- > > > > -- 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, > > > > > > IMO, The name prefix matters. The rte_* should denote it a DPDK API > > > and application suppose to use it. > > > > > It doesn't, its just a convention. We have no documentation that indicates > > what the meaning of an rte_* prefix is specficially, above and beyond the > > fact thats how we name functions in the DPDK. If you want to submit a patch > > to formalize the meaning of function prefixes, you're welcome too (though I > > won't support it, perhaps others will). But even if you do, it doesn't address > > the underlying problem, which is that applications still have access to those > > symbols. > > Maintaining an ABI by assertion of prefix is really a lousy way to communicate > > what functions should be accessed by an application and which shouldn't. If > > a function is exported, and included in the header file, people will try to use > > The current scheme in the driver/common is that, the header files are NOT made > It as public ie not installed make install. > The consumer driver includes that using relative path wrt DPDK source directory. > Well, thats a step in the right direction. I'd still like to see some enforcement to prevent the inadvertent use of those APIs though > Anyway I will add experimental section to make tool happy. > That really not the right solution. Marking them as experimental is just papering over the problem, and suggests to users that they will one day be stable. What you want is to explicitly mark those symbols as internal only, so that any inadvertent use gets flagged. Neil > >