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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 1554FC31E40 for ; Tue, 6 Aug 2019 12:22:20 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id B7767206A2 for ; Tue, 6 Aug 2019 12:22:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7767206A2 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 84AEC1B956; Tue, 6 Aug 2019 14:22:13 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id AC6051B955 for ; Tue, 6 Aug 2019 14:22:11 +0200 (CEST) Received: from cpe-2606-a000-111b-6140-0-0-0-162e.dyn6.twc.com ([2606:a000:111b:6140::162e] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1huyTa-00012a-6v; Tue, 06 Aug 2019 08:22:08 -0400 Date: Tue, 6 Aug 2019 08:21:34 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, Jerin Jacob Kollanukkaran , Bruce Richardson Message-ID: <20190806122134.GA3926@hmswarspite.think-freely.org> References: <20190525184346.27932-1-nhorman@tuxdriver.com> <20190613142344.9188-1-nhorman@tuxdriver.com> <1929042.qExNQAuVzC@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1929042.qExNQAuVzC@xps> User-Agent: Mutt/1.12.0 (2019-05-25) 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" On Tue, Aug 06, 2019 at 12:03:38PM +0200, Thomas Monjalon wrote: > I think it would be good to rebase and send at the beginning of the 19.11 cycle. > Thank you > I'm on PTO for the next 10 days or so, but yes, I'll take care of that asap. Thanks Neil > 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. > > > > >