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 5E592A00E6 for ; Wed, 12 Jun 2019 22:39:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 83EE01C499; Wed, 12 Jun 2019 22:39:22 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 159ED1B9C0 for ; Wed, 12 Jun 2019 22:39:20 +0200 (CEST) Received: from [107.15.85.130] (helo=hmswarspite.think-freely.org) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hbA1a-0004PR-26; Wed, 12 Jun 2019 16:39:16 -0400 Received: from hmswarspite.think-freely.org (localhost [127.0.0.1]) by hmswarspite.think-freely.org (8.15.2/8.15.2) with ESMTP id x5CKd7Dd016700; Wed, 12 Jun 2019 16:39:07 -0400 Received: (from nhorman@localhost) by hmswarspite.think-freely.org (8.15.2/8.15.2/Submit) id x5CKd5NG016693; Wed, 12 Jun 2019 16:39:05 -0400 From: Neil Horman To: dev@dpdk.org Cc: Neil Horman , Jerin Jacob Kollanukkaran , Bruce Richardson , Thomas Monjalon Date: Wed, 12 Jun 2019 16:38:54 -0400 Message-Id: <20190612203903.16565-1-nhorman@tuxdriver.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190525184346.27932-1-nhorman@tuxdriver.com> References: <20190525184346.27932-1-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: [dpdk-dev] [PATCH v1 0/9] 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" 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. Signed-off-by: Neil Horman CC: Jerin Jacob Kollanukkaran CC: Bruce Richardson CC: Thomas Monjalon