From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E21ABA00E6 for ; Tue, 6 Aug 2019 12:03:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE3351BE29; Tue, 6 Aug 2019 12:03:44 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 3796B1BE1F for ; Tue, 6 Aug 2019 12:03:43 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AC352413; Tue, 6 Aug 2019 06:03:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 06 Aug 2019 06:03:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=sxjwoo360kiEcaHi3EJmb3CYZeb8hOL+24UI/iPEOXk=; b=r1xw1vCMiElF tjPwaahRR7+7STeOS8itrx329L4y84+Fznd179xBXCDre8D2STTSTRId5cW7O/FV 8Tpv7xO5xh8JPqMRigpn1lvf0vToSVqNn7uJy58ajc7pJHd9QqM5BINeUxk/0vS1 1cIAsV7btyrQDUh9/RM3Tdp6JSpOTC0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=sxjwoo360kiEcaHi3EJmb3CYZeb8hOL+24UI/iPEO Xk=; b=ppUEg9YUEemOFKX307BO2ZJUpc48g7F8lhOzvmNfJ37cSPPUS4ygB1049 /BAV8xiYhOWvftoJCItE2Vr4FK26BpAP2a3Q0AZ4pSgpVUbbQLjwxsxu5PmVH4P8 Np5BzX3XCByps3/hmraTVRkXCNKdAwoxgTXtHwAbTD0Nftjk5wJXpa8+7uAKpdqD MeeCMe1bSb8zEjFa2GIXdxBHNXysghcLoozdFQvUwkP3/o/0mfBBDTrOKAbefVxZ pncRGJHwuAVJyx/gbDleLIdl8IFLs1XxtrtKKQW4UmuPtIFIHLzjAvYWs6o+vVA6 ixLXt9Sfg6VSXKANchv2JCtaqb+oA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddutddgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeelfedriedrudegledruddugeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 0933F80060; Tue, 6 Aug 2019 06:03:39 -0400 (EDT) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, Jerin Jacob Kollanukkaran , Bruce Richardson Date: Tue, 06 Aug 2019 12:03:38 +0200 Message-ID: <1929042.qExNQAuVzC@xps> In-Reply-To: <20190613142344.9188-1-nhorman@tuxdriver.com> References: <20190525184346.27932-1-nhorman@tuxdriver.com> <20190613142344.9188-1-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/10] dpdk: 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" I think it would be good to rebase and send at the beginning of the 19.11 cycle. Thank you 13/06/2019 16:23, Neil Horman: > 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, but I think it hits some of the high points, restricting symbol access > for any library that prototypes its public and private symbols in the same > header file, excluding the internal symbols from ABI constraints, and clearly > documenting those symbols which we wish to limit to internal usage.