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 8CCC3A0096 for ; Thu, 6 Jun 2019 18:56:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ACF881B970; Thu, 6 Jun 2019 18:56:25 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id B6E961B95D for ; Thu, 6 Jun 2019 18:56:24 +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 1hYvgX-00055u-Ho; Thu, 06 Jun 2019 12:56:20 -0400 Date: Thu, 6 Jun 2019 12:55:41 -0400 From: Neil Horman To: Jerin Jacob Kollanukkaran Cc: Bruce Richardson , "dev@dpdk.org" , Thomas Monjalon Message-ID: <20190606165541.GH29521@hmswarspite.think-freely.org> References: <20190605181108.GC554@hmswarspite.think-freely.org> <20190606113422.GA29521@hmswarspite.think-freely.org> <20190606133503.GB29521@hmswarspite.think-freely.org> <20190606150354.GF29521@hmswarspite.think-freely.org> <20190606152634.GG29521@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: -1.2 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag 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 Thu, Jun 06, 2019 at 04:23:26PM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: Neil Horman > > Sent: Thursday, June 6, 2019 8:57 PM > > To: Jerin Jacob Kollanukkaran > > Cc: Bruce Richardson ; dev@dpdk.org; > > Thomas Monjalon > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag > > > > On Thu, Jun 06, 2019 at 03:14:42PM +0000, Jerin Jacob Kollanukkaran wrote: > > > > > > > > > I don't have any strong opinion on name prefix vs marking as > > __rte_internal. > > > Or combination of both. I am fine any approach. > > > > > > I have only strong option on not to induce objdump dependency for > > checkpatch. > > > For the reason mentioned in http://mails.dpdk.org/archives/dev/2019- > > June/134160.html. > > > > > > > Sorry, in my haste I didn't fully adress this in your previous email > > > > I'm really uncertain what you mean by introducing a checkpatch dependency > > on objdump here. Theres nothing preventing you from running checkpatch > > before you build the library. The only thing checkpatch does in dpdk is scan > > the patches for sytle violations, and for changes in the map file for > > movement to and from the EXPERIMENTAL section (i.e. no use of objdump). > > > > My patch modifies check-experimental-syms.sh (adding an objdump scan for > > INTERNAL symbols, and renaming the script to check-special-syms.sh to be > > more meaningful). That script however, is not run by checkpatch, its run > > during compilation of the library to ensure that any symbol in a map file is > > also tagged with __rte_internal in the corresponding object). Theres no path > > from checkpatches to check-experimental-syms.sh > > > > What I meant in my last comment was that any dependency on objdump in > > check-[experimental|special]-syms.sh already existed prior to this patch. > > I see. I thought your patches addressing issue related to > http://patches.dpdk.org/patch/53590/ > It does, it just does it in a different way than you do it. > Where checkpatch.sh complaints when we add new internal driver API with > out rte_experimental? That's where all the discussion started. > The reason why I was saying the API name prefix to mark as internal API is > that checkpatch can detect that case. > Ah, thats a fair point, with my approach we need to add some code to check-symbol-change.sh such that any symbols listed in an INTERNAL section were ignored. That would provide behavioral compatibility to what you were doing in your patch. But regardless, there is no dependency on objdump that wasn't there before, are we in agreement on that? Neil > Example: > 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 > > > > > > So I'm unsure why you think checkpatches has a dependency. > > > > Neil > >