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 DC775A0096 for ; Wed, 5 Jun 2019 18:45:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2F9001B995; Wed, 5 Jun 2019 18:45:49 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 3AA8E1B993 for ; Wed, 5 Jun 2019 18:45:47 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2019 09:45:46 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by orsmga002.jf.intel.com with SMTP; 05 Jun 2019 09:45:42 -0700 Received: by (sSMTP sendmail emulation); Wed, 05 Jun 2019 17:45:41 +0100 Date: Wed, 5 Jun 2019 17:45:41 +0100 From: Bruce Richardson To: Jerin Jacob Kollanukkaran Cc: Neil Horman , "dev@dpdk.org" , Thomas Monjalon Message-ID: <20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com> References: <20190525184346.27932-1-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) 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 Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: Neil Horman > > Sent: Sunday, May 26, 2019 12:14 AM > > To: dev@dpdk.org > > Cc: Neil Horman ; Jerin Jacob Kollanukkaran > > ; Bruce Richardson ; > > Thomas Monjalon > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag > > > > Hey- > > Based on our recent conversations regarding the use of symbols only > > meant for internal dpdk consumption (between dpdk libraries), this is an idea > > that I've come up with that I'd like to get some feedback on > > > > Summary: > > 1) We have symbols in the DPDK that are meant to be used between DPDK > > libraries, but not by applications linking to them > > 2) We would like to document those symbols in the code, so as to note them > > clearly as for being meant for internal use only > > 3) Linker symbol visibility is a very coarse grained tool, and so there is no good > > way in a single library to mark items as being meant for use only by other > > DPDK libraries, at least not without some extensive runtime checking > > > > > > Proposal: > > I'm proposing that we introduce the __rte_internal tag. From a coding > > standpoint it works a great deal like the __rte_experimental tag in that it > > expempts the tagged symbol from ABI constraints (as the only users should > > be represented in the DPDK build environment). Additionally, the > > __rte_internal macro resolves differently based on the definition of the > > BUILDING_RTE_SDK flag (working under the assumption that said flag should > > only ever be set if we are actually building DPDK libraries which will make use > > of internal calls). If the BUILDING_RTE_SDK flag is set __rte_internal resolves > > to __attribute__((section "text.internal)), placing it in a special text section > > which is then used to validate that the the symbol appears in the INTERNAL > > section of the corresponding library version map). If BUILDING_RTE_SDK is > > not set, then __rte_internal resolves to __attribute__((error("..."))), which > > causes any caller of the tagged function to throw an error at compile time, > > indicating that the symbol is not available for external use. > > > > This isn't a perfect solution, as applications can still hack around it of course, > > I think, one way to, avoid, hack around could be to, > > 1) at config stage, create a random number for the build > 2) introduce RTE_CALL_INTERNAL macro for calling internal function, compare > the generated random number for allowing the calls to make within the library. i.e leverage the > fact that external library would never know the random number generated > for the DPDK build and internal driver code does. > Do we really need to care about this. If have some determined enough to hack around our limitations, then they surely know that they have an unsupported configuration. We just need to protect against inadvertent use of internals, IMHO. /Bruce