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 A3C4FA00E6 for ; Thu, 13 Jun 2019 09:54:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C2F401D004; Thu, 13 Jun 2019 09:53:59 +0200 (CEST) Received: from mail-vk1-f193.google.com (mail-vk1-f193.google.com [209.85.221.193]) by dpdk.org (Postfix) with ESMTP id DA2801D003 for ; Thu, 13 Jun 2019 09:53:57 +0200 (CEST) Received: by mail-vk1-f193.google.com with SMTP id 130so3887623vkn.9 for ; Thu, 13 Jun 2019 00:53:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wuNTryW8QVWBMgPuT/OQo2hyK3/ue498h8serX/CFaE=; b=nV+Mayxk1tJqEXE9l/ylqJvV9pFeSO2JhTmEJfqg+1s5fgq9//pgD5YvkJTUyNsU9c Yt6o2Vc14xdnP+msp9cpgJ+8FH+ygUD1g6extaBpjjt5ynNF6vy+F4Jw4jlzKnOT73JJ m0xYRe3j0b7OzqVyB8UVSbbqyO3j6LKX8lOPJH2jQw6C7veoAtTfJTl5rD3g0BvvU2hb avHSRewct0jSWNum504BAALTmE6mmr8AaAPfqBRTytQ2Ziz3TBCqiPqlv0YnQ07FnBDI 0qyxF//FPlDTh/PbSRu/eXvwlK5/lV1LDNwyyjD3jEZVZuBHszTcf0lRReBiDajhc2q3 pd9w== X-Gm-Message-State: APjAAAUvdKkZuIC+79Hj267efv9pRpB7UHlr0LUwQKZXpBAPXv+7Bnae fgr0+G/GXdkzG4Bj/533OqrYMMPv3yMaXjRgyKQWvw== X-Google-Smtp-Source: APXvYqwZKyK9kKM3LO0bmE1Wqfd9hQSXmWxDkg7lKet/G7MdToVLNAmyUy9kEeDjzqaNJ6PzvuiIylYkOy37s1K0OCc= X-Received: by 2002:a1f:5dc5:: with SMTP id r188mr3760353vkb.86.1560412437229; Thu, 13 Jun 2019 00:53:57 -0700 (PDT) MIME-Version: 1.0 References: <20190525184346.27932-1-nhorman@tuxdriver.com> <20190612203903.16565-1-nhorman@tuxdriver.com> In-Reply-To: <20190612203903.16565-1-nhorman@tuxdriver.com> From: David Marchand Date: Thu, 13 Jun 2019 09:53:46 +0200 Message-ID: To: Neil Horman Cc: dev , Jerin Jacob Kollanukkaran , Bruce Richardson , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [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" On Wed, Jun 12, 2019 at 10:40 PM Neil Horman wrote: > 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 > > > On the principle, are we not breaking the ABI for the libraries that we touch with this? Compilation is broken in patch 1 and 2 because the script rename is part of patch 3. -- David Marchand