Cover Comment List
List cover comments
GET /api/covers/54740/comments/?format=api
[ { "id": 97091, "web_url": "http://patches.dpdk.org/comment/97091/", "msgid": "<CAJFAV8wioyE04g7PuaTbsz65Y7hEkMtSUhVkHhWM+y4SwCPBQQ@mail.gmail.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CAJFAV8wioyE04g7PuaTbsz65Y7hEkMtSUhVkHhWM+y4SwCPBQQ@mail.gmail.com", "date": "2019-06-13T07:53:46", "subject": "Re: [dpdk-dev] [PATCH v1 0/9] dpdk: introduce __rte_internal tag", "submitter": { "id": 1173, "url": "http://patches.dpdk.org/api/people/1173/?format=api", "name": "David Marchand", "email": "david.marchand@redhat.com" }, "content": "On Wed, Jun 12, 2019 at 10:40 PM Neil Horman <nhorman@tuxdriver.com> wrote:\n\n> Hey-\n> Based on our recent conversations regarding the use of symbols only\n> meant for internal dpdk consumption (between dpdk libraries), this is an\n> idea\n> that I've come up with that I'd like to get some feedback on\n>\n> Summary:\n> 1) We have symbols in the DPDK that are meant to be used between DPDK\n> libraries,\n> but not by applications linking to them\n> 2) We would like to document those symbols in the code, so as to note them\n> clearly as for being meant for internal use only\n> 3) Linker symbol visibility is a very coarse grained tool, and so there is\n> no\n> good way in a single library to mark items as being meant for use only by\n> other\n> DPDK libraries, at least not without some extensive runtime checking\n>\n>\n> Proposal:\n> I'm proposing that we introduce the __rte_internal tag. From a coding\n> standpoint it works a great deal like the __rte_experimental tag in that it\n> expempts the tagged symbol from ABI constraints (as the only users should\n> be\n> represented in the DPDK build environment). Additionally, the\n> __rte_internal\n> macro resolves differently based on the definition of the BUILDING_RTE_SDK\n> flag\n> (working under the assumption that said flag should only ever be set if we\n> are\n> actually building DPDK libraries which will make use of internal calls).\n> If the\n> BUILDING_RTE_SDK flag is set __rte_internal resolves to\n> __attribute__((section\n> \"text.internal)), placing it in a special text section which is then used\n> to\n> validate that the the symbol appears in the INTERNAL section of the\n> corresponding library version map). If BUILDING_RTE_SDK is not set, then\n> __rte_internal resolves to __attribute__((error(\"...\"))), which causes any\n> caller of the tagged function to throw an error at compile time,\n> indicating that\n> the symbol is not available for external use.\n>\n> This isn't a perfect solution, as applications can still hack around it of\n> course, but I think it hits some of the high points, restricting symbol\n> access\n> for any library that prototypes its public and private symbols in the same\n> header file, excluding the internal symbols from ABI constraints, and\n> clearly\n> documenting those symbols which we wish to limit to internal usage.\n>\n> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>\n> CC: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> CC: Bruce Richardson <bruce.richardson@intel.com>\n> CC: Thomas Monjalon <thomas@monjalon.net>\n>\n>\n>\nOn the principle, are we not breaking the ABI for the libraries that we\ntouch with this?\n\nCompilation is broken in patch 1 and 2 because the script rename is part of\npatch 3.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id C2F401D004;\n\tThu, 13 Jun 2019 09:53:59 +0200 (CEST)", "from mail-vk1-f193.google.com (mail-vk1-f193.google.com\n\t[209.85.221.193]) by dpdk.org (Postfix) with ESMTP id DA2801D003\n\tfor <dev@dpdk.org>; Thu, 13 Jun 2019 09:53:57 +0200 (CEST)", "by mail-vk1-f193.google.com with SMTP id 130so3887623vkn.9\n\tfor <dev@dpdk.org>; Thu, 13 Jun 2019 00:53:57 -0700 (PDT)" ], "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=wuNTryW8QVWBMgPuT/OQo2hyK3/ue498h8serX/CFaE=;\n\tb=nV+Mayxk1tJqEXE9l/ylqJvV9pFeSO2JhTmEJfqg+1s5fgq9//pgD5YvkJTUyNsU9c\n\tYt6o2Vc14xdnP+msp9cpgJ+8FH+ygUD1g6extaBpjjt5ynNF6vy+F4Jw4jlzKnOT73JJ\n\tm0xYRe3j0b7OzqVyB8UVSbbqyO3j6LKX8lOPJH2jQw6C7veoAtTfJTl5rD3g0BvvU2hb\n\tavHSRewct0jSWNum504BAALTmE6mmr8AaAPfqBRTytQ2Ziz3TBCqiPqlv0YnQ07FnBDI\n\t0qyxF//FPlDTh/PbSRu/eXvwlK5/lV1LDNwyyjD3jEZVZuBHszTcf0lRReBiDajhc2q3\n\tpd9w==", "X-Gm-Message-State": "APjAAAUvdKkZuIC+79Hj267efv9pRpB7UHlr0LUwQKZXpBAPXv+7Bnae\n\tfgr0+G/GXdkzG4Bj/533OqrYMMPv3yMaXjRgyKQWvw==", "X-Google-Smtp-Source": "APXvYqwZKyK9kKM3LO0bmE1Wqfd9hQSXmWxDkg7lKet/G7MdToVLNAmyUy9kEeDjzqaNJ6PzvuiIylYkOy37s1K0OCc=", "X-Received": "by 2002:a1f:5dc5:: with SMTP id\n\tr188mr3760353vkb.86.1560412437229; \n\tThu, 13 Jun 2019 00:53:57 -0700 (PDT)", "MIME-Version": "1.0", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<20190612203903.16565-1-nhorman@tuxdriver.com>", "In-Reply-To": "<20190612203903.16565-1-nhorman@tuxdriver.com>", "From": "David Marchand <david.marchand@redhat.com>", "Date": "Thu, 13 Jun 2019 09:53:46 +0200", "Message-ID": "<CAJFAV8wioyE04g7PuaTbsz65Y7hEkMtSUhVkHhWM+y4SwCPBQQ@mail.gmail.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "Cc": "dev <dev@dpdk.org>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>, \n\tBruce Richardson <bruce.richardson@intel.com>,\n\tThomas Monjalon <thomas@monjalon.net>", "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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 97098, "web_url": "http://patches.dpdk.org/comment/97098/", "msgid": "<20190613103038.GB5381@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190613103038.GB5381@hmswarspite.think-freely.org", "date": "2019-06-13T10:30:38", "subject": "Re: [dpdk-dev] [PATCH v1 0/9] dpdk: introduce __rte_internal tag", "submitter": { "id": 32, "url": "http://patches.dpdk.org/api/people/32/?format=api", "name": "Neil Horman", "email": "nhorman@tuxdriver.com" }, "content": "On Thu, Jun 13, 2019 at 09:53:46AM +0200, David Marchand wrote:\n> On Wed, Jun 12, 2019 at 10:40 PM Neil Horman <nhorman@tuxdriver.com> wrote:\n> \n> > Hey-\n> > Based on our recent conversations regarding the use of symbols only\n> > meant for internal dpdk consumption (between dpdk libraries), this is an\n> > idea\n> > that I've come up with that I'd like to get some feedback on\n> >\n> > Summary:\n> > 1) We have symbols in the DPDK that are meant to be used between DPDK\n> > libraries,\n> > but not by applications linking to them\n> > 2) We would like to document those symbols in the code, so as to note them\n> > clearly as for being meant for internal use only\n> > 3) Linker symbol visibility is a very coarse grained tool, and so there is\n> > no\n> > good way in a single library to mark items as being meant for use only by\n> > other\n> > DPDK libraries, at least not without some extensive runtime checking\n> >\n> >\n> > Proposal:\n> > I'm proposing that we introduce the __rte_internal tag. From a coding\n> > standpoint it works a great deal like the __rte_experimental tag in that it\n> > expempts the tagged symbol from ABI constraints (as the only users should\n> > be\n> > represented in the DPDK build environment). Additionally, the\n> > __rte_internal\n> > macro resolves differently based on the definition of the BUILDING_RTE_SDK\n> > flag\n> > (working under the assumption that said flag should only ever be set if we\n> > are\n> > actually building DPDK libraries which will make use of internal calls).\n> > If the\n> > BUILDING_RTE_SDK flag is set __rte_internal resolves to\n> > __attribute__((section\n> > \"text.internal)), placing it in a special text section which is then used\n> > to\n> > validate that the the symbol appears in the INTERNAL section of the\n> > corresponding library version map). If BUILDING_RTE_SDK is not set, then\n> > __rte_internal resolves to __attribute__((error(\"...\"))), which causes any\n> > caller of the tagged function to throw an error at compile time,\n> > indicating that\n> > the symbol is not available for external use.\n> >\n> > This isn't a perfect solution, as applications can still hack around it of\n> > course, but I think it hits some of the high points, restricting symbol\n> > access\n> > for any library that prototypes its public and private symbols in the same\n> > header file, excluding the internal symbols from ABI constraints, and\n> > clearly\n> > documenting those symbols which we wish to limit to internal usage.\n> >\n> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>\n> > CC: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > CC: Bruce Richardson <bruce.richardson@intel.com>\n> > CC: Thomas Monjalon <thomas@monjalon.net>\n> >\n> >\n> >\n> On the principle, are we not breaking the ABI for the libraries that we\n> touch with this?\n> \nYes, strictly speaking on principle, we are, because we are removing symbols\nfrom the exported symbol list, but the purpose of this patch set was to identify\nthose symbols which, by (convention/documentation/etc), we had intended to\nmandate should never be used by applications outside of the DPDK. Since this\npatch is meant to identify those symbols, and somewhat more formally isolate and\nprevent users from accessing them, I was making the argument that it was ok to\ndo so. If you like we can go through the process of deprecating them, prior to\nmoving them to an internal space, but given that I was under the impression\nanyone reporting a bug about the symbol disappearing would be responded to with\na note indicating that they never should have been accessed to begin with, I had\nassumed the movement would be ok.\n\n> Compilation is broken in patch 1 and 2 because the script rename is part of\n> patch 3.\n> \nGood point, I'll reshuffle those to be more correct.\nNeil\n\n> \n> -- \n> David Marchand", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 7719B1D3A6;\n\tThu, 13 Jun 2019 12:30:55 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id EA1B91D14A\n\tfor <dev@dpdk.org>; Thu, 13 Jun 2019 12:30:53 +0200 (CEST)", "from [107.15.85.130] (helo=localhost)\n\tby smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63)\n\t(envelope-from <nhorman@tuxdriver.com>)\n\tid 1hbN0G-00083D-CW; Thu, 13 Jun 2019 06:30:51 -0400" ], "Date": "Thu, 13 Jun 2019 06:30:38 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "David Marchand <david.marchand@redhat.com>", "Cc": "dev <dev@dpdk.org>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>,\n\tBruce Richardson <bruce.richardson@intel.com>,\n\tThomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190613103038.GB5381@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<20190612203903.16565-1-nhorman@tuxdriver.com>\n\t<CAJFAV8wioyE04g7PuaTbsz65Y7hEkMtSUhVkHhWM+y4SwCPBQQ@mail.gmail.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<CAJFAV8wioyE04g7PuaTbsz65Y7hEkMtSUhVkHhWM+y4SwCPBQQ@mail.gmail.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]