From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A087C282DD for ; Thu, 23 May 2019 20:18:07 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 0793620644 for ; Thu, 23 May 2019 20:17:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0793620644 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=tuxdriver.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5DA4725D9; Thu, 23 May 2019 22:17:49 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 7344E3DC; Thu, 23 May 2019 22:17:48 +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 1hTu9g-0002v6-Vr; Thu, 23 May 2019 16:17:39 -0400 Date: Thu, 23 May 2019 16:17:09 -0400 From: Neil Horman To: Thomas Monjalon Cc: Jerin Jacob Kollanukkaran , Bruce Richardson , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20190523201709.GB18326@hmswarspite.think-freely.org> References: <20190523175752.GA18326@hmswarspite.think-freely.org> <9743169.QmDmBymccE@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9743169.QmDmBymccE@xps> User-Agent: Mutt/1.11.3 (2019-02-01) Subject: Re: [dpdk-dev] [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 Thu, May 23, 2019 at 08:59:07PM +0200, Thomas Monjalon wrote: > 23/05/2019 19:57, Neil Horman: > > On Thu, May 23, 2019 at 02:21:29PM +0000, Jerin Jacob Kollanukkaran wrote: > > > From: Neil Horman > > > > > > > > > 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 > > > > > > > > > > Yes header file is not exported. Not sure how a client can use those. > > > > > Other than doing some hacking. > > > > > > > > > Yes, self prototyping the exported functions would be a way around that. > > > > > > > > > > > > > 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. > > > > > > > > > > That what my original concern. > > > > > > > > > > > What you want is to explicitly mark those symbols as internal only, > > > > > > so that any inadvertent use gets flagged. > > > > > > > > > > What is your final thought? I can assume the following for my patch > > > > > generation > > > > > > > > > > # No need to mark as experimental > > > > > # Add @internal to denote it is a internal function like followed some places > > > > in EAL. > > > > > > > > > These are both correct, yes. > > > > > > > > In addition, I would like to see some mechanism that explicitly marks the > > > > function as exported only for the purposes of internal use. I understand that > > > > yours is a case in which this is not expressly needed because you don't > > > > prototype those functions, but what I'd like to see is a macro in rte_compat.h > > > > somewhere like this: > > > > > > > > #define INTERNAL_USE_ONLY do {static_assert(0, "Function is only available > > > > for internal DPDK usage");} while(0) > > > > > > > > so that, in your exported header file (of which I'm sure you have one, even if > > > > it doesn't contain your private functions, you can do something like this: > > > > > > > > #ifdef BUILDING_RTE_SDK > > > > void somefunc(int val); > > > > #else > > > > #define somefunc(x) INTERNAL_USE_ONLY > > > > #endif > > > > > > I think, We have two cases > > > 1) Internal functions are NOT available via DPDK SDK exported header files > > > 2) Internal functions are available via DPDK SDK exported header files > > > > > > I think, you are trying to address case 2( as case 1 is not applicable in this context due lack of header file) > > > For case 2, IMO, the above scheme will not be enough as > > > The consumer entity can simply add the exact C flags to skip that check in this case, -DBUILDING_RTE_SDK. > > > IMO, it would be correct remove private functions from public header files. No strong options on this. > > > > > > > I'm thinking about it a bit differently. Internal functions should never be > > available to user, weather they are prototyped in DPDK header files or not. > > Unfortunately, because of how library symbol exports work, there is no way to > > differentiate between which exported functions are internal or external, they > > are only exported or not, and as such, they are always resolveable by someone > > linking against them (regardless of which hackery is used to achieve that > > result). I'd like a way to prevent users who are only using the SDK (not > > building it) from accessing those symbols, and the above is the best solution I > > can come up with. I admit its not great, but it does place a roadblock in the > > way of users who attempt to use symbols we don't want to give them access to. > > And yes its circumventable by defining BUILDING_RTE_SDK, but I would think its > > clear that they are not building the SDK, and so they should not be doing that. > > > > Just not exporting the requisite header files is an easier solution, so if thats > > the consensus I can be ok with that, but I would really love to have a way to > > document in the code those functions which are not meant for external > > consumption. > > I think there are good ideas here. > Please come with a patch and we'll try to apply the chosen policy > to the existing code. > Ok, I'll give it a shot Neil > >