Cover Comment List
List cover comments
GET /api/covers/53698/comments/?format=api
[ { "id": 96791, "web_url": "http://patches.dpdk.org/comment/96791/", "msgid": "<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-05T16:24:09", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Sunday, May 26, 2019 12:14 AM\n> To: dev@dpdk.org\n> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob Kollanukkaran\n> <jerinj@marvell.com>; Bruce Richardson <bruce.richardson@intel.com>;\n> Thomas Monjalon <thomas@monjalon.net>\n> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> Hey-\n> \tBased on our recent conversations regarding the use of symbols only\n> meant for internal dpdk consumption (between dpdk libraries), this is an 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, 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 no good\n> way in a single library to mark items as being meant for use only by 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 represented in the DPDK build environment). Additionally, the\n> __rte_internal macro resolves differently based on the definition of the\n> BUILDING_RTE_SDK flag (working under the assumption that said flag should\n> only ever be set if we are actually building DPDK libraries which will make use\n> of internal calls). If the BUILDING_RTE_SDK flag is set __rte_internal resolves\n> to __attribute__((section \"text.internal)), placing it in a special text section\n> which is then used to validate that the the symbol appears in the INTERNAL\n> section of the corresponding library version map). If BUILDING_RTE_SDK is\n> not set, then __rte_internal resolves to __attribute__((error(\"...\"))), which\n> causes any caller of the tagged function to throw an error at compile time,\n> indicating that the symbol is not available for external use.\n> \n> This isn't a perfect solution, as applications can still hack around it of course,\n\nI think, one way to, avoid, hack around could be to,\n\n1) at config stage, create a random number for the build\n2) introduce RTE_CALL_INTERNAL macro for calling internal function, compare \nthe generated random number for allowing the calls to make within the library. i.e leverage the\nfact that external library would never know the random number generated \nfor the DPDK build and internal driver code does.\n\n\n> but I think it hits some of the high points, restricting symbol access for any\n> library that prototypes its public and private symbols in the same header file,\n> excluding the internal symbols from ABI constraints, and clearly documenting\n> those symbols which we wish to limit to internal usage.\n> \n> I've included a patch to the dpaa library to demonstrate its usage. If there is\n> consensus on this approach, I'll expand and repost the patch, pulling in the\n> other libraries which have internal-only symbol usage.\n> \n> Regards\n> Neil\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>", "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 891551BBB4;\n\tWed, 5 Jun 2019 18:24:14 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com\n\t[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 57EE31BA96\n\tfor <dev@dpdk.org>; Wed, 5 Jun 2019 18:24:13 +0200 (CEST)", "from pps.filterd (m0045849.ppops.net [127.0.0.1])\n\tby mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx55GJbpj001152; Wed, 5 Jun 2019 09:24:12 -0700", "from sc-exch03.marvell.com ([199.233.58.183])\n\tby mx0a-0016f401.pphosted.com with ESMTP id 2sxfw4ge3k-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tWed, 05 Jun 2019 09:24:12 -0700", "from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH03.marvell.com\n\t(10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tWed, 5 Jun 2019 09:24:11 -0700", "from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.56)\n\tby SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Wed, 5 Jun 2019 09:24:11 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2645.namprd18.prod.outlook.com (20.179.92.32) with Microsoft\n\tSMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1965.12; Wed, 5 Jun 2019 16:24:09 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tWed, 5 Jun 2019 16:24:09 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=ShvMDdnt6o2y2GYkpEbNjuzjDY07Yy3Tf7RAyxemdDU=;\n\tb=UNpFSQnkevoQ/pMJZ+zjI83iTx9dXllFFpvmQPvUUYbOKwV7TrODNE0OgGVKnxw+BJPx\n\tMnZqqdDKjGLVCqQKYOkma3SF1fqXcvxM8lWgNuXSZEV6hBD9LLD0JAV/6IdZtZLz7Phd\n\t6msfIq7zd+fArLYtKi8Fo+rkrhzB5DEg014ctY6bSRSjLe/w9OYWWL1IMSR/apGYzR6m\n\tZTstAekcucsddbe5ympcCf1Cd/zbqNeuC0FWXEbbI7i1jSZfTO8SqeT3W8y/5/1rY1tq\n\tmHZhLU4fkJjNVR3BSdM5mR8dTN7fEG/MtndcfagKUDTmHJ54IOj61wk/gkP9ETpPhYbY\n\tFA== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=ShvMDdnt6o2y2GYkpEbNjuzjDY07Yy3Tf7RAyxemdDU=;\n\tb=b8zdzjk5tLGMl+EDKNFl9GPtOzoru18HDj17L+/ySoAq2UADA398nauwHV3hs7zx4WvCgILBWaZPpQwhRMwy3u5nXQHfah30seCCJIK1ZFxXFGEK82nD2gasGJspGj6ppA1TWteQ7Njh5RKbb/52XOlo2sgnXeaWVWjorOC9dZM=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>, \"dev@dpdk.org\" <dev@dpdk.org>", "CC": "Bruce Richardson <bruce.richardson@intel.com>, Thomas Monjalon\n\t<thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQ", "Date": "Wed, 5 Jun 2019 16:24:09 +0000", "Message-ID": "<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>", "In-Reply-To": "<20190525184346.27932-1-nhorman@tuxdriver.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[122.178.234.223]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "d8cbf3c0-903c-44f0-9320-08d6e9d23cee", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2645; ", "x-ms-traffictypediagnostic": "BYAPR18MB2645:", "x-microsoft-antispam-prvs": "<BYAPR18MB26455AD07478FE8C98A3BB45C8160@BYAPR18MB2645.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:9508;", "x-forefront-prvs": "00594E8DBA", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(136003)(346002)(396003)(39850400004)(376002)(366004)(13464003)(174874002)(189003)(199004)(229853002)(74316002)(2906002)(14444005)(256004)(14454004)(110136005)(66476007)(66556008)(54906003)(186003)(6116002)(26005)(76116006)(316002)(3846002)(561944003)(55016002)(2501003)(478600001)(8676002)(7736002)(4326008)(305945005)(76176011)(25786009)(66066001)(7696005)(8936002)(81166006)(5660300002)(68736007)(52536014)(9686003)(81156014)(66946007)(73956011)(66446008)(64756008)(6246003)(102836004)(33656002)(99286004)(476003)(53936002)(6436002)(6506007)(53546011)(486006)(86362001)(446003)(71200400001)(11346002)(71190400001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2645;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; MX:1; A:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "YeYMKdsOXnX7oJCfXJyrVa2CfrR8VHx8OXijTVXmUBEctG+US+eNdnK7haBeyyJp7OXw6oMU2M/bSSUdl2MBIGpi4FMZ9sTOcFkOZRp0REZXSg/Hl2ZRx7z2TLLMRddX6jc9Z8xfbSDbl/1A09tuEY4PGRIW1Kgb8CzKfXuYDIhUfbg1WU3WWQtOmnhy/HSV/spNzCS5BQi+J1xQKDU+VTxK7OcrdUx9A8Oggedvg8edbHzEMy4OzraidfrlneuHnOuN1kvPgPFlyj4KzZfVld4zhr8S6yxsAD9e+khDh6xoMxUt8nuXI0xwG297VmelytEaqFqZmavyiQ14GMkJiXPzyZedpIge86njgSYvrapvRXxlxUUHxdeu+MkXXRRUsEFko8z/Qp1sMQZ821xSbj0OQcUD8KuiIvcAQnQJwrs=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "d8cbf3c0-903c-44f0-9320-08d6e9d23cee", "X-MS-Exchange-CrossTenant-originalarrivaltime": "05 Jun 2019 16:24:09.3036\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2645", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-05_09:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96801, "web_url": "http://patches.dpdk.org/comment/96801/", "msgid": "<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com", "date": "2019-06-05T16:45:41", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 20, "url": "http://patches.dpdk.org/api/people/20/?format=api", "name": "Bruce Richardson", "email": "bruce.richardson@intel.com" }, "content": "On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > -----Original Message-----\n> > From: Neil Horman <nhorman@tuxdriver.com>\n> > Sent: Sunday, May 26, 2019 12:14 AM\n> > To: dev@dpdk.org\n> > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob Kollanukkaran\n> > <jerinj@marvell.com>; Bruce Richardson <bruce.richardson@intel.com>;\n> > Thomas Monjalon <thomas@monjalon.net>\n> > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > \n> > Hey-\n> > \tBased on our recent conversations regarding the use of symbols only\n> > meant for internal dpdk consumption (between dpdk libraries), this is an 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, 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 no good\n> > way in a single library to mark items as being meant for use only by 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 represented in the DPDK build environment). Additionally, the\n> > __rte_internal macro resolves differently based on the definition of the\n> > BUILDING_RTE_SDK flag (working under the assumption that said flag should\n> > only ever be set if we are actually building DPDK libraries which will make use\n> > of internal calls). If the BUILDING_RTE_SDK flag is set __rte_internal resolves\n> > to __attribute__((section \"text.internal)), placing it in a special text section\n> > which is then used to validate that the the symbol appears in the INTERNAL\n> > section of the corresponding library version map). If BUILDING_RTE_SDK is\n> > not set, then __rte_internal resolves to __attribute__((error(\"...\"))), which\n> > causes any caller of the tagged function to throw an error at compile time,\n> > indicating that the symbol is not available for external use.\n> > \n> > This isn't a perfect solution, as applications can still hack around it of course,\n> \n> I think, one way to, avoid, hack around could be to,\n> \n> 1) at config stage, create a random number for the build\n> 2) introduce RTE_CALL_INTERNAL macro for calling internal function, compare \n> the generated random number for allowing the calls to make within the library. i.e leverage the\n> fact that external library would never know the random number generated \n> for the DPDK build and internal driver code does.\n> \nDo we really need to care about this. If have some determined enough to\nhack around our limitations, then they surely know that they have an\nunsupported configuration. We just need to protect against inadvertent use\nof internals, IMHO.\n\n/Bruce", "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 2F9001B995;\n\tWed, 5 Jun 2019 18:45:49 +0200 (CEST)", "from mga17.intel.com (mga17.intel.com [192.55.52.151])\n\tby dpdk.org (Postfix) with ESMTP id 3AA8E1B993\n\tfor <dev@dpdk.org>; Wed, 5 Jun 2019 18:45:47 +0200 (CEST)", "from orsmga002.jf.intel.com ([10.7.209.21])\n\tby fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t05 Jun 2019 09:45:46 -0700", "from bricha3-mobl.ger.corp.intel.com ([10.237.221.51])\n\tby orsmga002.jf.intel.com with SMTP; 05 Jun 2019 09:45:42 -0700", "by (sSMTP sendmail emulation); Wed, 05 Jun 2019 17:45:41 +0100" ], "X-Amp-Result": "UNKNOWN", "X-Amp-Original-Verdict": "FILE UNKNOWN", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "Date": "Wed, 5 Jun 2019 17:45:41 +0100", "From": "Bruce Richardson <bruce.richardson@intel.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Neil Horman <nhorman@tuxdriver.com>, \"dev@dpdk.org\" <dev@dpdk.org>,\n\tThomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.4 (2019-03-13)", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96812, "web_url": "http://patches.dpdk.org/comment/96812/", "msgid": "<20190605181108.GC554@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190605181108.GC554@hmswarspite.think-freely.org", "date": "2019-06-05T18:11:08", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > -----Original Message-----\n> > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > To: dev@dpdk.org\n> > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob Kollanukkaran\n> > > <jerinj@marvell.com>; Bruce Richardson <bruce.richardson@intel.com>;\n> > > Thomas Monjalon <thomas@monjalon.net>\n> > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > \n> > > Hey-\n> > > \tBased on our recent conversations regarding the use of symbols only\n> > > meant for internal dpdk consumption (between dpdk libraries), this is an 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, 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 no good\n> > > way in a single library to mark items as being meant for use only by 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 represented in the DPDK build environment). Additionally, the\n> > > __rte_internal macro resolves differently based on the definition of the\n> > > BUILDING_RTE_SDK flag (working under the assumption that said flag should\n> > > only ever be set if we are actually building DPDK libraries which will make use\n> > > of internal calls). If the BUILDING_RTE_SDK flag is set __rte_internal resolves\n> > > to __attribute__((section \"text.internal)), placing it in a special text section\n> > > which is then used to validate that the the symbol appears in the INTERNAL\n> > > section of the corresponding library version map). If BUILDING_RTE_SDK is\n> > > not set, then __rte_internal resolves to __attribute__((error(\"...\"))), which\n> > > causes any caller of the tagged function to throw an error at compile time,\n> > > indicating that the symbol is not available for external use.\n> > > \n> > > This isn't a perfect solution, as applications can still hack around it of course,\n> > \n> > I think, one way to, avoid, hack around could be to,\n> > \n> > 1) at config stage, create a random number for the build\n> > 2) introduce RTE_CALL_INTERNAL macro for calling internal function, compare \n> > the generated random number for allowing the calls to make within the library. i.e leverage the\n> > fact that external library would never know the random number generated \n> > for the DPDK build and internal driver code does.\n> > \n> Do we really need to care about this. If have some determined enough to\n> hack around our limitations, then they surely know that they have an\n> unsupported configuration. We just need to protect against inadvertent use\n> of internals, IMHO.\n> \nI agree, I too had thought about doing some sort of internal runtime checking to\nmatch internal only symbols, such that they were only accessable by internally\napproved users, but it started to feel like a great deal of overhead. Its a\ngood idea for a general mechanism I think, but I believe the value here is more\nto internally document which apis we want to mark as being for internal use\nonly, and create a lightweight roadblock at build time to catch users\ninadvertently using them. Determined users will get around anything, and theres\nnot much we can do to stop them.\n\nIf we really wanted to go down that road, we could use a mechainsm simmilar to\nthe EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure that the kernel uses, but\nthat would required building our own custom linker script, which seems like\noverkill here.\n\nBest\nNeil\n\n> /Bruce\n>", "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 120031B9B5;\n\tWed, 5 Jun 2019 20:11:52 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id 68C211B9C3\n\tfor <dev@dpdk.org>; Wed, 5 Jun 2019 20:11:50 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYaNt-00039J-56; Wed, 05 Jun 2019 14:11:46 -0400" ], "Date": "Wed, 5 Jun 2019 14:11:08 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Bruce Richardson <bruce.richardson@intel.com>", "Cc": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190605181108.GC554@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96843, "web_url": "http://patches.dpdk.org/comment/96843/", "msgid": "<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-06T09:44:52", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Wednesday, June 5, 2019 11:41 PM\n> To: Bruce Richardson <bruce.richardson@intel.com>\n> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Thomas\n> Monjalon <thomas@monjalon.net>\n> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran\n> wrote:\n> > > > -----Original Message-----\n> > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > To: dev@dpdk.org\n> > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob Kollanukkaran\n> > > > <jerinj@marvell.com>; Bruce Richardson\n> > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > <thomas@monjalon.net>\n> > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > >\n> > > > Hey-\n> > > > \tBased on our recent conversations regarding the use of symbols\n> > > > only meant for internal dpdk consumption (between dpdk libraries),\n> > > > this is an idea that I've come up with that I'd like to get some\n> > > > feedback on\n> > > >\n> > > > Summary:\n> > > > 1) We have symbols in the DPDK that are meant to be used between\n> > > > DPDK libraries, but not by applications linking to them\n> > > > 2) We would like to document those symbols in the code, so as to\n> > > > note them clearly as for being meant for internal use only\n> > > > 3) Linker symbol visibility is a very coarse grained tool, and so\n> > > > there is no good way in a single library to mark items as being\n> > > > meant for use only by other DPDK libraries, at least not without\n> > > > some extensive runtime checking\n> > > >\n> > > >\n> > > > Proposal:\n> > > > I'm proposing that we introduce the __rte_internal tag. From a\n> > > > coding standpoint it works a great deal like the\n> > > > __rte_experimental tag in that it expempts the tagged symbol from\n> > > > ABI constraints (as the only users should be represented in the\n> > > > DPDK build environment). Additionally, the __rte_internal macro\n> > > > resolves differently based on the definition of the\n> > > > BUILDING_RTE_SDK flag (working under the assumption that said flag\n> > > > should only ever be set if we are actually building DPDK libraries\n> > > > which will make use of internal calls). If the BUILDING_RTE_SDK\n> > > > flag is set __rte_internal resolves to __attribute__((section\n> > > > \"text.internal)), placing it in a special text section which is\n> > > > then used to validate that the the symbol appears in the INTERNAL\n> > > > section of the corresponding library version map). If\n> > > > BUILDING_RTE_SDK is not set, then __rte_internal resolves to\n> __attribute__((error(\"...\"))), which causes any caller of the tagged function\n> to throw an error at compile time, indicating that the symbol is not available\n> for external use.\n> > > >\n> > > > This isn't a perfect solution, as applications can still hack\n> > > > around it of course,\n> > >\n> > > I think, one way to, avoid, hack around could be to,\n> > >\n> > > 1) at config stage, create a random number for the build\n> > > 2) introduce RTE_CALL_INTERNAL macro for calling internal function,\n> > > compare the generated random number for allowing the calls to make\n> > > within the library. i.e leverage the fact that external library\n> > > would never know the random number generated for the DPDK build\n> and internal driver code does.\n> > >\n> > Do we really need to care about this. If have some determined enough\n> > to hack around our limitations, then they surely know that they have\n> > an unsupported configuration. We just need to protect against\n> > inadvertent use of internals, IMHO.\n> >\n> I agree, I too had thought about doing some sort of internal runtime checking\n> to match internal only symbols, such that they were only accessable by\n> internally approved users, but it started to feel like a great deal of overhead.\n> Its a good idea for a general mechanism I think, but I believe the value here is\n> more to internally document which apis we want to mark as being for\n> internal use only, and create a lightweight roadblock at build time to catch\n> users inadvertently using them. Determined users will get around anything,\n> and theres not much we can do to stop them.\n\nI agree too. IMHO, Simply having following items would be enough\n\n1) Avoid exposing the internal function prototype through public header files\n2) Add @internal to API documentation\n3) Just decide the name space for internal API for tooling(i.e not start with rte_ or so)\nUsing objdump scheme to detect internal functions requires the the library to build prior to run the checkpatch.\n\n> \n> If we really wanted to go down that road, we could use a mechainsm\n> simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure that\n> the kernel uses, but that would required building our own custom linker\n> script, which seems like overkill here.\n> \n> Best\n> Neil\n> \n> > /Bruce\n> >", "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 BD8C31B95A;\n\tThu, 6 Jun 2019 11:45:00 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com\n\t[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 833741B959\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 11:44:59 +0200 (CEST)", "from pps.filterd (m0045849.ppops.net [127.0.0.1])\n\tby mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx569ivAb010202; Thu, 6 Jun 2019 02:44:58 -0700", "from sc-exch03.marvell.com ([199.233.58.183])\n\tby mx0a-0016f401.pphosted.com with ESMTP id 2sxwgnrpgd-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tThu, 06 Jun 2019 02:44:58 -0700", "from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH03.marvell.com\n\t(10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tThu, 6 Jun 2019 02:44:57 -0700", "from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.52)\n\tby SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 02:44:57 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2949.namprd18.prod.outlook.com (20.179.59.153) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1965.12; Thu, 6 Jun 2019 09:44:52 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tThu, 6 Jun 2019 09:44:52 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=tsYCd9OtEOLxh9a7Dzfz1UdsjZOsUA8vWPxRVROkGsE=;\n\tb=yLFYis5j4IrG3KhT196Va+u2g39ulHvbP4inLBdaUi53U6zyzlBAysk34BMOa5MAznPx\n\tonc+JISEcbq52bl4SbIETBtctwmshUjIKShBtDycA0xdS6o4aO5V5T0GMmPgtFntNMMg\n\tfN4zBE8zJjqylHMMjZh4KBpq41q8EwfF2SnyzA0E2U/c+0qvT8qA6WycsIrGet6oxjFx\n\tMvgLe/Gm8SLOSRUbZHMNM1Br0cJ6SucndBWCjPzWYHIckEYyswIIoIZuVVbp8dffuySD\n\tSKTfm4eBFmTaCA3RdhTBF2en/cmlJVeYdbCq3bQK0gANNFvSyvsyDmxzRRVDYcZ/pymU\n\t0Q== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=tsYCd9OtEOLxh9a7Dzfz1UdsjZOsUA8vWPxRVROkGsE=;\n\tb=Hrh3ZBsQN761wJ8gPRxxhPralswVp6j6cq5WtsKOU634iJMni3cKTMdvsBsfa4no/b3KeS82HMzaU3tbbZHAuo/SbgRBJ/i11bAQAx7GawpwwlTacMXZyIrOjPtjGFQMUnuQXqR06odfHYyPF1MsMwuL8c14mJIwxTt/fZBG89k=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>, Bruce Richardson\n\t<bruce.richardson@intel.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyA", "Date": "Thu, 6 Jun 2019 09:44:52 +0000", "Message-ID": "<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>", "In-Reply-To": "<20190605181108.GC554@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[14.140.231.66]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "b5cea67b-5ec2-443c-68c3-08d6ea63a02f", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2949; ", "x-ms-traffictypediagnostic": "BYAPR18MB2949:", "x-microsoft-antispam-prvs": "<BYAPR18MB2949AEF8272296470C701C35C8170@BYAPR18MB2949.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-forefront-prvs": "00603B7EEF", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39860400002)(13464003)(174874002)(199004)(189003)(4326008)(73956011)(316002)(64756008)(66446008)(66476007)(66556008)(66946007)(76116006)(3846002)(6116002)(7736002)(14454004)(25786009)(305945005)(53936002)(8936002)(478600001)(8676002)(81156014)(6246003)(81166006)(74316002)(102836004)(86362001)(99286004)(76176011)(7696005)(55016002)(55236004)(68736007)(229853002)(66066001)(53546011)(6506007)(110136005)(6436002)(11346002)(446003)(33656002)(476003)(54906003)(52536014)(5660300002)(186003)(14444005)(256004)(2906002)(71200400001)(71190400001)(26005)(9686003)(486006)(561944003);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2949;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; A:1; MX:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "8WooXZvjLP/UBne2NUD+9BnkUdrBgcshjrjmL3smuKKyaU30CEP50DmuWzQCFD0m6f3dI9ikbKeKzOLfq7y0qSSeaicz0xqEbChdhq6zYQ0muFPMuzrcL/IdVCLfAjLHNE+5rCJyOvG5bx84a9GVaaxOQjU4Udrrwk2+AoZKi1L6rCY6/sYOT1bft7ZmQ+0yXnWCreWPaVM5hj8HDW3QQAKLDBzXHvkjZ+YfXMtTyt22BDRs/+ZTs1cFADLUjIkAYWDINbvbUamTEL+1ILruCeRylCbXa+rox0V378zwMjPzuSc8oSjhMaqQxnTp0ZEhaZ6mpwlmCjCKheAGtL8T8Tdkgwi3+DDsZfnjbfqsso6RqhlsdhmVLdpFPq9H1qiqA5RrXfA8q05MLo8A7Ghz0wYYx7Oo9AmZJcjEvDWbMDo=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "b5cea67b-5ec2-443c-68c3-08d6ea63a02f", "X-MS-Exchange-CrossTenant-originalarrivaltime": "06 Jun 2019 09:44:52.7718\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2949", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-06_08:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96854, "web_url": "http://patches.dpdk.org/comment/96854/", "msgid": "<20190606113422.GA29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606113422.GA29521@hmswarspite.think-freely.org", "date": "2019-06-06T11:34:22", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n> > -----Original Message-----\n> > From: Neil Horman <nhorman@tuxdriver.com>\n> > Sent: Wednesday, June 5, 2019 11:41 PM\n> > To: Bruce Richardson <bruce.richardson@intel.com>\n> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Thomas\n> > Monjalon <thomas@monjalon.net>\n> > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > \n> > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran\n> > wrote:\n> > > > > -----Original Message-----\n> > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > > To: dev@dpdk.org\n> > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob Kollanukkaran\n> > > > > <jerinj@marvell.com>; Bruce Richardson\n> > > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > > <thomas@monjalon.net>\n> > > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > > >\n> > > > > Hey-\n> > > > > \tBased on our recent conversations regarding the use of symbols\n> > > > > only meant for internal dpdk consumption (between dpdk libraries),\n> > > > > this is an idea that I've come up with that I'd like to get some\n> > > > > feedback on\n> > > > >\n> > > > > Summary:\n> > > > > 1) We have symbols in the DPDK that are meant to be used between\n> > > > > DPDK libraries, but not by applications linking to them\n> > > > > 2) We would like to document those symbols in the code, so as to\n> > > > > note them clearly as for being meant for internal use only\n> > > > > 3) Linker symbol visibility is a very coarse grained tool, and so\n> > > > > there is no good way in a single library to mark items as being\n> > > > > meant for use only by other DPDK libraries, at least not without\n> > > > > some extensive runtime checking\n> > > > >\n> > > > >\n> > > > > Proposal:\n> > > > > I'm proposing that we introduce the __rte_internal tag. From a\n> > > > > coding standpoint it works a great deal like the\n> > > > > __rte_experimental tag in that it expempts the tagged symbol from\n> > > > > ABI constraints (as the only users should be represented in the\n> > > > > DPDK build environment). Additionally, the __rte_internal macro\n> > > > > resolves differently based on the definition of the\n> > > > > BUILDING_RTE_SDK flag (working under the assumption that said flag\n> > > > > should only ever be set if we are actually building DPDK libraries\n> > > > > which will make use of internal calls). If the BUILDING_RTE_SDK\n> > > > > flag is set __rte_internal resolves to __attribute__((section\n> > > > > \"text.internal)), placing it in a special text section which is\n> > > > > then used to validate that the the symbol appears in the INTERNAL\n> > > > > section of the corresponding library version map). If\n> > > > > BUILDING_RTE_SDK is not set, then __rte_internal resolves to\n> > __attribute__((error(\"...\"))), which causes any caller of the tagged function\n> > to throw an error at compile time, indicating that the symbol is not available\n> > for external use.\n> > > > >\n> > > > > This isn't a perfect solution, as applications can still hack\n> > > > > around it of course,\n> > > >\n> > > > I think, one way to, avoid, hack around could be to,\n> > > >\n> > > > 1) at config stage, create a random number for the build\n> > > > 2) introduce RTE_CALL_INTERNAL macro for calling internal function,\n> > > > compare the generated random number for allowing the calls to make\n> > > > within the library. i.e leverage the fact that external library\n> > > > would never know the random number generated for the DPDK build\n> > and internal driver code does.\n> > > >\n> > > Do we really need to care about this. If have some determined enough\n> > > to hack around our limitations, then they surely know that they have\n> > > an unsupported configuration. We just need to protect against\n> > > inadvertent use of internals, IMHO.\n> > >\n> > I agree, I too had thought about doing some sort of internal runtime checking\n> > to match internal only symbols, such that they were only accessable by\n> > internally approved users, but it started to feel like a great deal of overhead.\n> > Its a good idea for a general mechanism I think, but I believe the value here is\n> > more to internally document which apis we want to mark as being for\n> > internal use only, and create a lightweight roadblock at build time to catch\n> > users inadvertently using them. Determined users will get around anything,\n> > and theres not much we can do to stop them.\n> \n> I agree too. IMHO, Simply having following items would be enough\n> \n> 1) Avoid exposing the internal function prototype through public header files\n> 2) Add @internal to API documentation\n> 3) Just decide the name space for internal API for tooling(i.e not start with rte_ or so)\n> Using objdump scheme to detect internal functions requires the the library to build prior to run the checkpatch.\n> \n\nNo, I'm not comfortable with that approach, and I've stated why:\n1) Not exposing the functions via header files is a fine start\n\n2) Adding internal documentation is also fine, but does nothing to correlate the\ncode implementing those functions to the documentation. Its valuable to have a\ntag on a function identifying it as internal only.\n\n3) Using naming conventions to separate internal only from non-internal\nfunctions is a vague approach, requiring future developers to be cogniscent of\nthe convention and make the appropriate naming choices. It also implicitly\nrestricts the abliity for future developers to make naming changes in conflict\nwith that convention\n\n4) Adding a tag like __rte_internal creates an interlock whereby, not only are\ninternal functions excused from ABI constraints, but forces developers to\nintentionally mark their internal functions as being internal in the code, which\nis beneficial to clarlity of understanding during the development process.\n\n5) Adding a tag like __rte_internal is explicit, and allows developers to use a\nsingle header file instead of multiple header files if they so choose\n\nWe went through this with experimental symbols as well[1], and it just makes\nmore sense to me to clearly document in the code what constitutes an internal\nsymbol rather than relying on naming conventions and hoping that developers read\nthe documentation before exporting a symbol publically.\n\n\n[1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> > \n> > If we really wanted to go down that road, we could use a mechainsm\n> > simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure that\n> > the kernel uses, but that would required building our own custom linker\n> > script, which seems like overkill here.\n> > \n> > Best\n> > Neil\n> > \n> > > /Bruce\n> > >\n>", "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 9A63D1B99A;\n\tThu, 6 Jun 2019 13:35:01 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id 13A1E1B993\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 13:35:00 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYqfT-0001dz-Gw; Thu, 06 Jun 2019 07:34:55 -0400" ], "Date": "Thu, 6 Jun 2019 07:34:22 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Bruce Richardson <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606113422.GA29521@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96855, "web_url": "http://patches.dpdk.org/comment/96855/", "msgid": "<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-06T12:04:57", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Thursday, June 6, 2019 5:04 PM\n> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> Thomas Monjalon <thomas@monjalon.net>\n> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > -----Original Message-----\n> > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > Sent: Wednesday, June 5, 2019 11:41 PM\n> > > To: Bruce Richardson <bruce.richardson@intel.com>\n> > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org;\n> > > Thomas Monjalon <thomas@monjalon.net>\n> > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > >\n> > > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> > > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> > > > Kollanukkaran\n> > > wrote:\n> > > > > > -----Original Message-----\n> > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > > > To: dev@dpdk.org\n> > > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> > > > > > Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> > > > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > > > <thomas@monjalon.net>\n> > > > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > > > >\n> > > > > > Hey-\n> > > > > > \tBased on our recent conversations regarding the use of\n> > > > > > symbols only meant for internal dpdk consumption (between dpdk\n> > > > > > libraries), this is an idea that I've come up with that I'd\n> > > > > > like to get some feedback on\n> > > > > >\n> > > > > > Summary:\n> > > > > > 1) We have symbols in the DPDK that are meant to be used\n> > > > > > between DPDK libraries, but not by applications linking to\n> > > > > > them\n> > > > > > 2) We would like to document those symbols in the code, so as\n> > > > > > to note them clearly as for being meant for internal use only\n> > > > > > 3) Linker symbol visibility is a very coarse grained tool, and\n> > > > > > so there is no good way in a single library to mark items as\n> > > > > > being meant for use only by other DPDK libraries, at least not\n> > > > > > without some extensive runtime checking\n> > > > > >\n> > > > > >\n> > > > > > Proposal:\n> > > > > > I'm proposing that we introduce the __rte_internal tag. From\n> > > > > > a coding standpoint it works a great deal like the\n> > > > > > __rte_experimental tag in that it expempts the tagged symbol\n> > > > > > from ABI constraints (as the only users should be represented\n> > > > > > in the DPDK build environment). Additionally, the\n> > > > > > __rte_internal macro resolves differently based on the\n> > > > > > definition of the BUILDING_RTE_SDK flag (working under the\n> > > > > > assumption that said flag should only ever be set if we are\n> > > > > > actually building DPDK libraries which will make use of\n> > > > > > internal calls). If the BUILDING_RTE_SDK flag is set\n> > > > > > __rte_internal resolves to __attribute__((section\n> > > > > > \"text.internal)), placing it in a special text section which\n> > > > > > is then used to validate that the the symbol appears in the\n> > > > > > INTERNAL section of the corresponding library version map).\n> > > > > > If BUILDING_RTE_SDK is not set, then __rte_internal resolves\n> > > > > > to\n> > > __attribute__((error(\"...\"))), which causes any caller of the tagged\n> > > function to throw an error at compile time, indicating that the\n> > > symbol is not available for external use.\n> > > > > >\n> > > > > > This isn't a perfect solution, as applications can still hack\n> > > > > > around it of course,\n> > > > >\n> > > > > I think, one way to, avoid, hack around could be to,\n> > > > >\n> > > > > 1) at config stage, create a random number for the build\n> > > > > 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> > > > > function, compare the generated random number for allowing the\n> > > > > calls to make within the library. i.e leverage the fact that\n> > > > > external library would never know the random number generated\n> > > > > for the DPDK build\n> > > and internal driver code does.\n> > > > >\n> > > > Do we really need to care about this. If have some determined\n> > > > enough to hack around our limitations, then they surely know that\n> > > > they have an unsupported configuration. We just need to protect\n> > > > against inadvertent use of internals, IMHO.\n> > > >\n> > > I agree, I too had thought about doing some sort of internal runtime\n> > > checking to match internal only symbols, such that they were only\n> > > accessable by internally approved users, but it started to feel like a great\n> deal of overhead.\n> > > Its a good idea for a general mechanism I think, but I believe the\n> > > value here is more to internally document which apis we want to mark\n> > > as being for internal use only, and create a lightweight roadblock\n> > > at build time to catch users inadvertently using them. Determined\n> > > users will get around anything, and theres not much we can do to stop\n> them.\n> >\n> > I agree too. IMHO, Simply having following items would be enough\n> >\n> > 1) Avoid exposing the internal function prototype through public\n> > header files\n> > 2) Add @internal to API documentation\n> > 3) Just decide the name space for internal API for tooling(i.e not\n> > start with rte_ or so) Using objdump scheme to detect internal functions\n> requires the the library to build prior to run the checkpatch.\n> >\n> \n> No, I'm not comfortable with that approach, and I've stated why:\n> 1) Not exposing the functions via header files is a fine start\n> \n> 2) Adding internal documentation is also fine, but does nothing to correlate\n> the code implementing those functions to the documentation. Its valuable\n> to have a tag on a function identifying it as internal only.\n> \n> 3) Using naming conventions to separate internal only from non-internal\n> functions is a vague approach, requiring future developers to be cogniscent\n> of the convention and make the appropriate naming choices. It also implicitly\n> restricts the abliity for future developers to make naming changes in conflict\n> with that convention\n\nEnforcing the naming convention can be achieved through tooling as well.\n\n> \n> 4) Adding a tag like __rte_internal creates an interlock whereby, not only are\n> internal functions excused from ABI constraints, but forces developers to\n> intentionally mark their internal functions as being internal in the code, which\n> is beneficial to clarlity of understanding during the development process.\n\nNo issues in adding __rte_internal. But, I am against current implementaion, \nIe. adding objdump dependency\nto checkpatch i.e developer has to build the library first so that checkpatch can\ncan know, Is it belongs to internal section or not?\n\n> \n> 5) Adding a tag like __rte_internal is explicit, and allows developers to use a\n> single header file instead of multiple header files if they so choose\n> \n> We went through this with experimental symbols as well[1], and it just\n> makes more sense to me to clearly document in the code what constitutes\n> an internal symbol rather than relying on naming conventions and hoping\n> that developers read the documentation before exporting a symbol\n> publically.\n> \n> \n> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> > >\n> > > If we really wanted to go down that road, we could use a mechainsm\n> > > simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure\n> > > that the kernel uses, but that would required building our own\n> > > custom linker script, which seems like overkill here.\n> > >\n> > > Best\n> > > Neil\n> > >\n> > > > /Bruce\n> > > >\n> >", "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 8664D1B9BB;\n\tThu, 6 Jun 2019 14:05:05 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com\n\t[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 2524A1B9B9\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 14:05:03 +0200 (CEST)", "from pps.filterd (m0045849.ppops.net [127.0.0.1])\n\tby mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx56BuG5m021407; Thu, 6 Jun 2019 05:05:03 -0700", "from sc-exch03.marvell.com ([199.233.58.183])\n\tby mx0a-0016f401.pphosted.com with ESMTP id 2sxwgns5xv-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tThu, 06 Jun 2019 05:05:02 -0700", "from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com\n\t(10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tThu, 6 Jun 2019 05:05:02 -0700", "from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.59)\n\tby SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 05:05:02 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2630.namprd18.prod.outlook.com (20.179.94.155) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1943.22; Thu, 6 Jun 2019 12:04:57 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tThu, 6 Jun 2019 12:04:57 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=cs0encbbpO6VyvHmooHfoc8WemIjHsF08IbAYsnimSU=;\n\tb=v2/rBizQCfZJrppoOfKr8euwY4rFfUIg9/+2jfVSq8z/eyqf0fTaGjHAeHBpL2N/SXWB\n\tg11FsZxK7aH3/UCp3E3heDvhsnBB1if6JW7HsBF7SsPFSsKyaZCgopzP/fTUdI1f39ZE\n\tY9ptK+M9udNqVefnSj67Ylu6ifgdhvO0LJyrTVp5yfZLEyTl65ehieiN7H9LwaCVrzOY\n\tGtb21JHaZax48YL/7/0GFJbyuSJb2GW04D2Jmnc0jORW5RdzFS5cVMzEbSbIYDyiUMd6\n\tp93cG9H23ZKHoXgUfFEoX1iXze2/7hOoyoUYlZ42wuycUV4iHKLNdpPoFIWWmZOYpurV\n\tmw== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=cs0encbbpO6VyvHmooHfoc8WemIjHsF08IbAYsnimSU=;\n\tb=Ff07Fjrbsm5HGurF8JE8K0H7eQWmWnnUIhyyD0DWFfYzqph4GkVqpvPJJnXWuQjkvNU8r2AsKAQkqySlN6pXHzxCuXZomK4WFUVKpZTLoW+ukTf/Ea8HuFij4sDc9sQC/a6l5PEtl5fNABF+aXwZp+/UzXaby/DUy/RMUMV31dU=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "CC": "Bruce Richardson <bruce.richardson@intel.com>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyAgAAgfgCAAAaRkA==", "Date": "Thu, 6 Jun 2019 12:04:57 +0000", "Message-ID": "<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>", "In-Reply-To": "<20190606113422.GA29521@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[122.178.234.223]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "4d55e92c-3272-43fc-fcdd-08d6ea7731be", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2630; ", "x-ms-traffictypediagnostic": "BYAPR18MB2630:", "x-ms-exchange-purlcount": "1", "x-microsoft-antispam-prvs": "<BYAPR18MB263077F947731CDE969586CFC8170@BYAPR18MB2630.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-forefront-prvs": "00603B7EEF", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(346002)(376002)(39860400002)(366004)(396003)(136003)(189003)(174874002)(199004)(13464003)(8936002)(76116006)(561944003)(11346002)(316002)(73956011)(6916009)(33656002)(81166006)(81156014)(6246003)(8676002)(66476007)(446003)(64756008)(66446008)(66556008)(66946007)(102836004)(68736007)(53936002)(476003)(4326008)(26005)(6506007)(486006)(71190400001)(53546011)(71200400001)(3846002)(6116002)(6436002)(6306002)(54906003)(229853002)(7736002)(76176011)(55016002)(305945005)(74316002)(52536014)(9686003)(186003)(99286004)(966005)(14454004)(86362001)(2906002)(5660300002)(478600001)(25786009)(7696005)(66066001)(14444005)(256004);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2630;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; MX:1; A:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "t257VD+az+TVL3CwL+nP7M6ZthbxtiKxppn+he1l3NdSkbuJlAOjUPOHs8NOqDGdPZGdPA3XYsajRKuPMItFw8QOmyZI0//DwleXaKrhfV9mBS7Qr1h5bwSmznWJDeQFiEPmbKccKmXxY1wLlUxr7Ys/MRz9vOuODyJBpWtyvp89nCT+puffA0/1kaO+9WkuFujd877u1uKkS3dsRISUU+sL6ivaz5zhRDgH6dXLSrEoNmOCrCmcNsDxNqxH7YBdVNm7V2puwh/r9eMgwaTLW/OQm9QJOxWgamLgrfMPVMSGOtheQwONlU8SpFwXz87d8yJ2XBI9Udjd+NPH/Rk86Ejdk1riiSgSkNE4ItvN0NJbl1mdmeiBwScyZwr8zH+7J+86JT4BwS/yk2mGRKTXpGmShlymPZkzvX+5+kmPKgQ=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "4d55e92c-3272-43fc-fcdd-08d6ea7731be", "X-MS-Exchange-CrossTenant-originalarrivaltime": "06 Jun 2019 12:04:57.4672\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2630", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-06_10:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96858, "web_url": "http://patches.dpdk.org/comment/96858/", "msgid": "<015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com", "date": "2019-06-06T13:18:29", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 166, "url": "http://patches.dpdk.org/api/people/166/?format=api", "name": "Wiles, Keith", "email": "keith.wiles@intel.com" }, "content": "> On Jun 6, 2019, at 7:04 AM, Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:\n> \n>> -----Original Message-----\n>> From: Neil Horman <nhorman@tuxdriver.com>\n>> Sent: Thursday, June 6, 2019 5:04 PM\n>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n>> Thomas Monjalon <thomas@monjalon.net>\n>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>> \n>> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n>>>> -----Original Message-----\n>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>> Sent: Wednesday, June 5, 2019 11:41 PM\n>>>> To: Bruce Richardson <bruce.richardson@intel.com>\n>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org;\n>>>> Thomas Monjalon <thomas@monjalon.net>\n>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>> \n>>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n>>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n>>>>> Kollanukkaran\n>>>> wrote:\n>>>>>>> -----Original Message-----\n>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n>>>>>>> To: dev@dpdk.org\n>>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n>>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n>>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n>>>>>>> <thomas@monjalon.net>\n>>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>>> \n>>>>>>> Hey-\n>>>>>>> \tBased on our recent conversations regarding the use of\n>>>>>>> symbols only meant for internal dpdk consumption (between dpdk\n>>>>>>> libraries), this is an idea that I've come up with that I'd\n>>>>>>> like to get some feedback on\n>>>>>>> \n>>>>>>> Summary:\n>>>>>>> 1) We have symbols in the DPDK that are meant to be used\n>>>>>>> between DPDK libraries, but not by applications linking to\n>>>>>>> them\n>>>>>>> 2) We would like to document those symbols in the code, so as\n>>>>>>> to note them clearly as for being meant for internal use only\n>>>>>>> 3) Linker symbol visibility is a very coarse grained tool, and\n>>>>>>> so there is no good way in a single library to mark items as\n>>>>>>> being meant for use only by other DPDK libraries, at least not\n>>>>>>> without some extensive runtime checking\n>>>>>>> \n>>>>>>> \n>>>>>>> Proposal:\n>>>>>>> I'm proposing that we introduce the __rte_internal tag. From\n>>>>>>> a coding standpoint it works a great deal like the\n>>>>>>> __rte_experimental tag in that it expempts the tagged symbol\n>>>>>>> from ABI constraints (as the only users should be represented\n>>>>>>> in the DPDK build environment). Additionally, the\n>>>>>>> __rte_internal macro resolves differently based on the\n>>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n>>>>>>> assumption that said flag should only ever be set if we are\n>>>>>>> actually building DPDK libraries which will make use of\n>>>>>>> internal calls). If the BUILDING_RTE_SDK flag is set\n>>>>>>> __rte_internal resolves to __attribute__((section\n>>>>>>> \"text.internal)), placing it in a special text section which\n>>>>>>> is then used to validate that the the symbol appears in the\n>>>>>>> INTERNAL section of the corresponding library version map).\n>>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal resolves\n>>>>>>> to\n>>>> __attribute__((error(\"...\"))), which causes any caller of the tagged\n>>>> function to throw an error at compile time, indicating that the\n>>>> symbol is not available for external use.\n>>>>>>> \n>>>>>>> This isn't a perfect solution, as applications can still hack\n>>>>>>> around it of course,\n>>>>>> \n>>>>>> I think, one way to, avoid, hack around could be to,\n>>>>>> \n>>>>>> 1) at config stage, create a random number for the build\n>>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n>>>>>> function, compare the generated random number for allowing the\n>>>>>> calls to make within the library. i.e leverage the fact that\n>>>>>> external library would never know the random number generated\n>>>>>> for the DPDK build\n>>>> and internal driver code does.\n>>>>>> \n>>>>> Do we really need to care about this. If have some determined\n>>>>> enough to hack around our limitations, then they surely know that\n>>>>> they have an unsupported configuration. We just need to protect\n>>>>> against inadvertent use of internals, IMHO.\n>>>>> \n>>>> I agree, I too had thought about doing some sort of internal runtime\n>>>> checking to match internal only symbols, such that they were only\n>>>> accessable by internally approved users, but it started to feel like a great\n>> deal of overhead.\n>>>> Its a good idea for a general mechanism I think, but I believe the\n>>>> value here is more to internally document which apis we want to mark\n>>>> as being for internal use only, and create a lightweight roadblock\n>>>> at build time to catch users inadvertently using them. Determined\n>>>> users will get around anything, and theres not much we can do to stop\n>> them.\n>>> \n>>> I agree too. IMHO, Simply having following items would be enough\n>>> \n>>> 1) Avoid exposing the internal function prototype through public\n>>> header files\n>>> 2) Add @internal to API documentation\n>>> 3) Just decide the name space for internal API for tooling(i.e not\n>>> start with rte_ or so) Using objdump scheme to detect internal functions\n>> requires the the library to build prior to run the checkpatch.\n>>> \n>> \n>> No, I'm not comfortable with that approach, and I've stated why:\n>> 1) Not exposing the functions via header files is a fine start\n>> \n>> 2) Adding internal documentation is also fine, but does nothing to correlate\n>> the code implementing those functions to the documentation. Its valuable\n>> to have a tag on a function identifying it as internal only.\n>> \n>> 3) Using naming conventions to separate internal only from non-internal\n>> functions is a vague approach, requiring future developers to be cogniscent\n>> of the convention and make the appropriate naming choices. It also implicitly\n>> restricts the abliity for future developers to make naming changes in conflict\n>> with that convention\n> \n> Enforcing the naming convention can be achieved through tooling as well.\n> \n>> \n>> 4) Adding a tag like __rte_internal creates an interlock whereby, not only are\n>> internal functions excused from ABI constraints, but forces developers to\n>> intentionally mark their internal functions as being internal in the code, which\n>> is beneficial to clarlity of understanding during the development process.\n> \n> No issues in adding __rte_internal. But, I am against current implementaion, \n> Ie. adding objdump dependency\n> to checkpatch i.e developer has to build the library first so that checkpatch can\n> can know, Is it belongs to internal section or not?\n> \n>> \n>> 5) Adding a tag like __rte_internal is explicit, and allows developers to use a\n>> single header file instead of multiple header files if they so choose\n>> \n>> We went through this with experimental symbols as well[1], and it just\n>> makes more sense to me to clearly document in the code what constitutes\n>> an internal symbol rather than relying on naming conventions and hoping\n>> that developers read the documentation before exporting a symbol\n>> publically.\n\nI feel like we are creating a lot of extra work for the developer and adding a number of constraints to getting code patches submitted as the tools all have to be working together. The versioning file and __rte_experimental stuff today has always being handle wrong or not done by the developer. Altering the tools to detect these changes works and it seemed to take a while to iron out. To me we should be doing the minimum steps to reasonably isolate internal API and data from the user. If someone wants to access the those APIs that is their choice and enforcing with new macros and tools is over kill IMHO.\n\n1) Adding @internal to documentation is a great start along with more docs to explain what internal functions/data should be handled.\n2) Hiding/moving internal function prototypes in private headers.\n3) Adding setters/getters for internal data.\n4) Make sure we review and reject direct use of internal functions and data.\n\nThe goal here is to handle the 80% rule and make it very obvious to the developer these are internal functions and data. Using these or similar minimum steps should be reasonable IMHO.\n>> \n>> \n>> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n>>>> \n>>>> If we really wanted to go down that road, we could use a mechainsm\n>>>> simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure\n>>>> that the kernel uses, but that would required building our own\n>>>> custom linker script, which seems like overkill here.\n>>>> \n>>>> Best\n>>>> Neil\n>>>> \n>>>>> /Bruce\n\nRegards,\nKeith", "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 4A70B1B95A;\n\tThu, 6 Jun 2019 15:18:33 +0200 (CEST)", "from mga12.intel.com (mga12.intel.com [192.55.52.136])\n\tby dpdk.org (Postfix) with ESMTP id B0E091B958\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 15:18:30 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t06 Jun 2019 06:18:29 -0700", "from fmsmsx105.amr.corp.intel.com ([10.18.124.203])\n\tby fmsmga001.fm.intel.com with ESMTP; 06 Jun 2019 06:18:29 -0700", "from fmsmsx111.amr.corp.intel.com (10.18.116.5) by\n\tFMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP\n\tServer (TLS) id 14.3.408.0; Thu, 6 Jun 2019 06:18:29 -0700", "from fmsmsx117.amr.corp.intel.com ([169.254.3.141]) by\n\tfmsmsx111.amr.corp.intel.com ([169.254.12.164]) with mapi id\n\t14.03.0415.000; Thu, 6 Jun 2019 06:18:29 -0700" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "From": "\"Wiles, Keith\" <keith.wiles@intel.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "CC": "Neil Horman <nhorman@tuxdriver.com>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"dev@dpdk.org\" <dev@dpdk.org>,\n\tThomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVHGAeTHy0x+iqgUew6BEqMONpAqaPEUAA", "Date": "Thu, 6 Jun 2019 13:18:29 +0000", "Message-ID": "<015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "In-Reply-To": "<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[10.255.75.4]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-ID": "<D28A95B38A5F614A9B2C3F7E3E42490A@intel.com>", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96860, "web_url": "http://patches.dpdk.org/comment/96860/", "msgid": "<20190606133503.GB29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606133503.GB29521@hmswarspite.think-freely.org", "date": "2019-06-06T13:35:03", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > -----Original Message-----\n> > From: Neil Horman <nhorman@tuxdriver.com>\n> > Sent: Thursday, June 6, 2019 5:04 PM\n> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > Thomas Monjalon <thomas@monjalon.net>\n> > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > \n> > On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > > -----Original Message-----\n> > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > Sent: Wednesday, June 5, 2019 11:41 PM\n> > > > To: Bruce Richardson <bruce.richardson@intel.com>\n> > > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org;\n> > > > Thomas Monjalon <thomas@monjalon.net>\n> > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > >\n> > > > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> > > > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> > > > > Kollanukkaran\n> > > > wrote:\n> > > > > > > -----Original Message-----\n> > > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > > > > To: dev@dpdk.org\n> > > > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> > > > > > > Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> > > > > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > > > > <thomas@monjalon.net>\n> > > > > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > > > > >\n> > > > > > > Hey-\n> > > > > > > \tBased on our recent conversations regarding the use of\n> > > > > > > symbols only meant for internal dpdk consumption (between dpdk\n> > > > > > > libraries), this is an idea that I've come up with that I'd\n> > > > > > > like to get some feedback on\n> > > > > > >\n> > > > > > > Summary:\n> > > > > > > 1) We have symbols in the DPDK that are meant to be used\n> > > > > > > between DPDK libraries, but not by applications linking to\n> > > > > > > them\n> > > > > > > 2) We would like to document those symbols in the code, so as\n> > > > > > > to note them clearly as for being meant for internal use only\n> > > > > > > 3) Linker symbol visibility is a very coarse grained tool, and\n> > > > > > > so there is no good way in a single library to mark items as\n> > > > > > > being meant for use only by other DPDK libraries, at least not\n> > > > > > > without some extensive runtime checking\n> > > > > > >\n> > > > > > >\n> > > > > > > Proposal:\n> > > > > > > I'm proposing that we introduce the __rte_internal tag. From\n> > > > > > > a coding standpoint it works a great deal like the\n> > > > > > > __rte_experimental tag in that it expempts the tagged symbol\n> > > > > > > from ABI constraints (as the only users should be represented\n> > > > > > > in the DPDK build environment). Additionally, the\n> > > > > > > __rte_internal macro resolves differently based on the\n> > > > > > > definition of the BUILDING_RTE_SDK flag (working under the\n> > > > > > > assumption that said flag should only ever be set if we are\n> > > > > > > actually building DPDK libraries which will make use of\n> > > > > > > internal calls). If the BUILDING_RTE_SDK flag is set\n> > > > > > > __rte_internal resolves to __attribute__((section\n> > > > > > > \"text.internal)), placing it in a special text section which\n> > > > > > > is then used to validate that the the symbol appears in the\n> > > > > > > INTERNAL section of the corresponding library version map).\n> > > > > > > If BUILDING_RTE_SDK is not set, then __rte_internal resolves\n> > > > > > > to\n> > > > __attribute__((error(\"...\"))), which causes any caller of the tagged\n> > > > function to throw an error at compile time, indicating that the\n> > > > symbol is not available for external use.\n> > > > > > >\n> > > > > > > This isn't a perfect solution, as applications can still hack\n> > > > > > > around it of course,\n> > > > > >\n> > > > > > I think, one way to, avoid, hack around could be to,\n> > > > > >\n> > > > > > 1) at config stage, create a random number for the build\n> > > > > > 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> > > > > > function, compare the generated random number for allowing the\n> > > > > > calls to make within the library. i.e leverage the fact that\n> > > > > > external library would never know the random number generated\n> > > > > > for the DPDK build\n> > > > and internal driver code does.\n> > > > > >\n> > > > > Do we really need to care about this. If have some determined\n> > > > > enough to hack around our limitations, then they surely know that\n> > > > > they have an unsupported configuration. We just need to protect\n> > > > > against inadvertent use of internals, IMHO.\n> > > > >\n> > > > I agree, I too had thought about doing some sort of internal runtime\n> > > > checking to match internal only symbols, such that they were only\n> > > > accessable by internally approved users, but it started to feel like a great\n> > deal of overhead.\n> > > > Its a good idea for a general mechanism I think, but I believe the\n> > > > value here is more to internally document which apis we want to mark\n> > > > as being for internal use only, and create a lightweight roadblock\n> > > > at build time to catch users inadvertently using them. Determined\n> > > > users will get around anything, and theres not much we can do to stop\n> > them.\n> > >\n> > > I agree too. IMHO, Simply having following items would be enough\n> > >\n> > > 1) Avoid exposing the internal function prototype through public\n> > > header files\n> > > 2) Add @internal to API documentation\n> > > 3) Just decide the name space for internal API for tooling(i.e not\n> > > start with rte_ or so) Using objdump scheme to detect internal functions\n> > requires the the library to build prior to run the checkpatch.\n> > >\n> > \n> > No, I'm not comfortable with that approach, and I've stated why:\n> > 1) Not exposing the functions via header files is a fine start\n> > \n> > 2) Adding internal documentation is also fine, but does nothing to correlate\n> > the code implementing those functions to the documentation. Its valuable\n> > to have a tag on a function identifying it as internal only.\n> > \n> > 3) Using naming conventions to separate internal only from non-internal\n> > functions is a vague approach, requiring future developers to be cogniscent\n> > of the convention and make the appropriate naming choices. It also implicitly\n> > restricts the abliity for future developers to make naming changes in conflict\n> > with that convention\n> \n> Enforcing the naming convention can be achieved through tooling as well.\n> \nSure, but why enforce any function naming at all, when you don't have to.\n\n> > \n> > 4) Adding a tag like __rte_internal creates an interlock whereby, not only are\n> > internal functions excused from ABI constraints, but forces developers to\n> > intentionally mark their internal functions as being internal in the code, which\n> > is beneficial to clarlity of understanding during the development process.\n> \n> No issues in adding __rte_internal. But, I am against current implementaion, \n> Ie. adding objdump dependency\nThat dependency already exists for the __rte_external flag\n\n> to checkpatch i.e developer has to build the library first so that checkpatch can\n> can know, Is it belongs to internal section or not?\n> \nWhat developer is running checkpatch/posting patches without first building\ntheir changes?\n\n\n> > \n> > 5) Adding a tag like __rte_internal is explicit, and allows developers to use a\n> > single header file instead of multiple header files if they so choose\n> > \n> > We went through this with experimental symbols as well[1], and it just\n> > makes more sense to me to clearly document in the code what constitutes\n> > an internal symbol rather than relying on naming conventions and hoping\n> > that developers read the documentation before exporting a symbol\n> > publically.\n> > \n> > \n> > [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> > > >\n> > > > If we really wanted to go down that road, we could use a mechainsm\n> > > > simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure\n> > > > that the kernel uses, but that would required building our own\n> > > > custom linker script, which seems like overkill here.\n> > > >\n> > > > Best\n> > > > Neil\n> > > >\n> > > > > /Bruce\n> > > > >\n> > >\n>", "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 E0C641B95A;\n\tThu, 6 Jun 2019 15:35:47 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id 3257F1B958\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 15:35:47 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYsYJ-0002v7-S7; Thu, 06 Jun 2019 09:35:42 -0400" ], "Date": "Thu, 6 Jun 2019 09:35:03 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Bruce Richardson <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606133503.GB29521@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96862, "web_url": "http://patches.dpdk.org/comment/96862/", "msgid": "<20190606134300.GC29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606134300.GC29521@hmswarspite.think-freely.org", "date": "2019-06-06T13:43:00", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 01:18:29PM +0000, Wiles, Keith wrote:\n> \n> \n> > On Jun 6, 2019, at 7:04 AM, Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:\n> > \n> >> -----Original Message-----\n> >> From: Neil Horman <nhorman@tuxdriver.com>\n> >> Sent: Thursday, June 6, 2019 5:04 PM\n> >> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> >> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> >> Thomas Monjalon <thomas@monjalon.net>\n> >> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >> \n> >> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n> >>>> -----Original Message-----\n> >>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>> Sent: Wednesday, June 5, 2019 11:41 PM\n> >>>> To: Bruce Richardson <bruce.richardson@intel.com>\n> >>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org;\n> >>>> Thomas Monjalon <thomas@monjalon.net>\n> >>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>> \n> >>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> >>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> >>>>> Kollanukkaran\n> >>>> wrote:\n> >>>>>>> -----Original Message-----\n> >>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n> >>>>>>> To: dev@dpdk.org\n> >>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> >>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> >>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n> >>>>>>> <thomas@monjalon.net>\n> >>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>>>>> \n> >>>>>>> Hey-\n> >>>>>>> \tBased on our recent conversations regarding the use of\n> >>>>>>> symbols only meant for internal dpdk consumption (between dpdk\n> >>>>>>> libraries), this is an idea that I've come up with that I'd\n> >>>>>>> like to get some feedback on\n> >>>>>>> \n> >>>>>>> Summary:\n> >>>>>>> 1) We have symbols in the DPDK that are meant to be used\n> >>>>>>> between DPDK libraries, but not by applications linking to\n> >>>>>>> them\n> >>>>>>> 2) We would like to document those symbols in the code, so as\n> >>>>>>> to note them clearly as for being meant for internal use only\n> >>>>>>> 3) Linker symbol visibility is a very coarse grained tool, and\n> >>>>>>> so there is no good way in a single library to mark items as\n> >>>>>>> being meant for use only by other DPDK libraries, at least not\n> >>>>>>> without some extensive runtime checking\n> >>>>>>> \n> >>>>>>> \n> >>>>>>> Proposal:\n> >>>>>>> I'm proposing that we introduce the __rte_internal tag. From\n> >>>>>>> a coding standpoint it works a great deal like the\n> >>>>>>> __rte_experimental tag in that it expempts the tagged symbol\n> >>>>>>> from ABI constraints (as the only users should be represented\n> >>>>>>> in the DPDK build environment). Additionally, the\n> >>>>>>> __rte_internal macro resolves differently based on the\n> >>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n> >>>>>>> assumption that said flag should only ever be set if we are\n> >>>>>>> actually building DPDK libraries which will make use of\n> >>>>>>> internal calls). If the BUILDING_RTE_SDK flag is set\n> >>>>>>> __rte_internal resolves to __attribute__((section\n> >>>>>>> \"text.internal)), placing it in a special text section which\n> >>>>>>> is then used to validate that the the symbol appears in the\n> >>>>>>> INTERNAL section of the corresponding library version map).\n> >>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal resolves\n> >>>>>>> to\n> >>>> __attribute__((error(\"...\"))), which causes any caller of the tagged\n> >>>> function to throw an error at compile time, indicating that the\n> >>>> symbol is not available for external use.\n> >>>>>>> \n> >>>>>>> This isn't a perfect solution, as applications can still hack\n> >>>>>>> around it of course,\n> >>>>>> \n> >>>>>> I think, one way to, avoid, hack around could be to,\n> >>>>>> \n> >>>>>> 1) at config stage, create a random number for the build\n> >>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> >>>>>> function, compare the generated random number for allowing the\n> >>>>>> calls to make within the library. i.e leverage the fact that\n> >>>>>> external library would never know the random number generated\n> >>>>>> for the DPDK build\n> >>>> and internal driver code does.\n> >>>>>> \n> >>>>> Do we really need to care about this. If have some determined\n> >>>>> enough to hack around our limitations, then they surely know that\n> >>>>> they have an unsupported configuration. We just need to protect\n> >>>>> against inadvertent use of internals, IMHO.\n> >>>>> \n> >>>> I agree, I too had thought about doing some sort of internal runtime\n> >>>> checking to match internal only symbols, such that they were only\n> >>>> accessable by internally approved users, but it started to feel like a great\n> >> deal of overhead.\n> >>>> Its a good idea for a general mechanism I think, but I believe the\n> >>>> value here is more to internally document which apis we want to mark\n> >>>> as being for internal use only, and create a lightweight roadblock\n> >>>> at build time to catch users inadvertently using them. Determined\n> >>>> users will get around anything, and theres not much we can do to stop\n> >> them.\n> >>> \n> >>> I agree too. IMHO, Simply having following items would be enough\n> >>> \n> >>> 1) Avoid exposing the internal function prototype through public\n> >>> header files\n> >>> 2) Add @internal to API documentation\n> >>> 3) Just decide the name space for internal API for tooling(i.e not\n> >>> start with rte_ or so) Using objdump scheme to detect internal functions\n> >> requires the the library to build prior to run the checkpatch.\n> >>> \n> >> \n> >> No, I'm not comfortable with that approach, and I've stated why:\n> >> 1) Not exposing the functions via header files is a fine start\n> >> \n> >> 2) Adding internal documentation is also fine, but does nothing to correlate\n> >> the code implementing those functions to the documentation. Its valuable\n> >> to have a tag on a function identifying it as internal only.\n> >> \n> >> 3) Using naming conventions to separate internal only from non-internal\n> >> functions is a vague approach, requiring future developers to be cogniscent\n> >> of the convention and make the appropriate naming choices. It also implicitly\n> >> restricts the abliity for future developers to make naming changes in conflict\n> >> with that convention\n> > \n> > Enforcing the naming convention can be achieved through tooling as well.\n> > \n> >> \n> >> 4) Adding a tag like __rte_internal creates an interlock whereby, not only are\n> >> internal functions excused from ABI constraints, but forces developers to\n> >> intentionally mark their internal functions as being internal in the code, which\n> >> is beneficial to clarlity of understanding during the development process.\n> > \n> > No issues in adding __rte_internal. But, I am against current implementaion, \n> > Ie. adding objdump dependency\n> > to checkpatch i.e developer has to build the library first so that checkpatch can\n> > can know, Is it belongs to internal section or not?\n> > \n> >> \n> >> 5) Adding a tag like __rte_internal is explicit, and allows developers to use a\n> >> single header file instead of multiple header files if they so choose\n> >> \n> >> We went through this with experimental symbols as well[1], and it just\n> >> makes more sense to me to clearly document in the code what constitutes\n> >> an internal symbol rather than relying on naming conventions and hoping\n> >> that developers read the documentation before exporting a symbol\n> >> publically.\n> \n> I feel like we are creating a lot of extra work for the developer and adding a number of constraints to getting code patches submitted as the tools all have to be working together. The versioning file and __rte_experimental stuff today has always being handle wrong or not done by the developer. Altering the tools to detect these changes works and it seemed to take a while to iron out. To me we should be doing the minimum steps to reasonably isolate internal API and data from the user. If someone wants to access the those APIs that is their choice and enforcing with new macros and tools is over kill IMHO.\n> \n> 1) Adding @internal to documentation is a great start along with more docs to explain what internal functions/data should be handled.\nI've got no issue with this\n> 2) Hiding/moving internal function prototypes in private headers.\nNor this, though if you want to do it, ensuring that every library has a private\nheader that doesn't get exported has to be part of the review process, and I'm\nnot confident that that will be a focus of anyones review\n\n> 3) Adding setters/getters for internal data.\nSure, no issue here\n> 4) Make sure we review and reject direct use of internal functions and data.\nHow exactly do you intend to enforce this? By definition, the use of internal\nfunctions is restricted only to dpdk core libraries, and those are the only\npatches we ever see on the list. This change is meant to enforce usage\nprevention for users writing applications whos patches will never be seen for\nreview (save for our example programs)\n\nWe already have this mechanism available for experimental abi, and from my\nperspective it works quite well, and is fairly well understood. I don't see\nwhats wrong with expanding that mechanism to internal functions.\n\nNeil\n\n> \n> The goal here is to handle the 80% rule and make it very obvious to the developer these are internal functions and data. Using these or similar minimum steps should be reasonable IMHO.\n> >> \n> >> \n> >> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> >>>> \n> >>>> If we really wanted to go down that road, we could use a mechainsm\n> >>>> simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure\n> >>>> that the kernel uses, but that would required building our own\n> >>>> custom linker script, which seems like overkill here.\n> >>>> \n> >>>> Best\n> >>>> Neil\n> >>>> \n> >>>>> /Bruce\n> \n> Regards,\n> Keith\n> \n>", "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 B06781B993;\n\tThu, 6 Jun 2019 15:43:35 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id 6338B1B974\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 15:43:34 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYsfv-00030h-7Q; Thu, 06 Jun 2019 09:43:30 -0400" ], "Date": "Thu, 6 Jun 2019 09:43:00 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "\"Wiles, Keith\" <keith.wiles@intel.com>", "Cc": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>,\n\t\"Richardson, Bruce\" <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606134300.GC29521@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-1.2 (-)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96863, "web_url": "http://patches.dpdk.org/comment/96863/", "msgid": "<AF2ECFBD-F3B6-4580-86B7-F93BDB7FB34B@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/AF2ECFBD-F3B6-4580-86B7-F93BDB7FB34B@intel.com", "date": "2019-06-06T13:53:47", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 166, "url": "http://patches.dpdk.org/api/people/166/?format=api", "name": "Wiles, Keith", "email": "keith.wiles@intel.com" }, "content": "> On Jun 6, 2019, at 8:43 AM, Neil Horman <nhorman@tuxdriver.com> wrote:\n> \n> On Thu, Jun 06, 2019 at 01:18:29PM +0000, Wiles, Keith wrote:\n>> \n>> \n>>> On Jun 6, 2019, at 7:04 AM, Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:\n>>> \n>>>> -----Original Message-----\n>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>> Sent: Thursday, June 6, 2019 5:04 PM\n>>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n>>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n>>>> Thomas Monjalon <thomas@monjalon.net>\n>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>> \n>>>> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n>>>>>> -----Original Message-----\n>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>> Sent: Wednesday, June 5, 2019 11:41 PM\n>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>\n>>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org;\n>>>>>> Thomas Monjalon <thomas@monjalon.net>\n>>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>> \n>>>>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n>>>>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n>>>>>>> Kollanukkaran\n>>>>>> wrote:\n>>>>>>>>> -----Original Message-----\n>>>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n>>>>>>>>> To: dev@dpdk.org\n>>>>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n>>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n>>>>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n>>>>>>>>> <thomas@monjalon.net>\n>>>>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>>>>> \n>>>>>>>>> Hey-\n>>>>>>>>> \tBased on our recent conversations regarding the use of\n>>>>>>>>> symbols only meant for internal dpdk consumption (between dpdk\n>>>>>>>>> libraries), this is an idea that I've come up with that I'd\n>>>>>>>>> like to get some feedback on\n>>>>>>>>> \n>>>>>>>>> Summary:\n>>>>>>>>> 1) We have symbols in the DPDK that are meant to be used\n>>>>>>>>> between DPDK libraries, but not by applications linking to\n>>>>>>>>> them\n>>>>>>>>> 2) We would like to document those symbols in the code, so as\n>>>>>>>>> to note them clearly as for being meant for internal use only\n>>>>>>>>> 3) Linker symbol visibility is a very coarse grained tool, and\n>>>>>>>>> so there is no good way in a single library to mark items as\n>>>>>>>>> being meant for use only by other DPDK libraries, at least not\n>>>>>>>>> without some extensive runtime checking\n>>>>>>>>> \n>>>>>>>>> \n>>>>>>>>> Proposal:\n>>>>>>>>> I'm proposing that we introduce the __rte_internal tag. From\n>>>>>>>>> a coding standpoint it works a great deal like the\n>>>>>>>>> __rte_experimental tag in that it expempts the tagged symbol\n>>>>>>>>> from ABI constraints (as the only users should be represented\n>>>>>>>>> in the DPDK build environment). Additionally, the\n>>>>>>>>> __rte_internal macro resolves differently based on the\n>>>>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n>>>>>>>>> assumption that said flag should only ever be set if we are\n>>>>>>>>> actually building DPDK libraries which will make use of\n>>>>>>>>> internal calls). If the BUILDING_RTE_SDK flag is set\n>>>>>>>>> __rte_internal resolves to __attribute__((section\n>>>>>>>>> \"text.internal)), placing it in a special text section which\n>>>>>>>>> is then used to validate that the the symbol appears in the\n>>>>>>>>> INTERNAL section of the corresponding library version map).\n>>>>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal resolves\n>>>>>>>>> to\n>>>>>> __attribute__((error(\"...\"))), which causes any caller of the tagged\n>>>>>> function to throw an error at compile time, indicating that the\n>>>>>> symbol is not available for external use.\n>>>>>>>>> \n>>>>>>>>> This isn't a perfect solution, as applications can still hack\n>>>>>>>>> around it of course,\n>>>>>>>> \n>>>>>>>> I think, one way to, avoid, hack around could be to,\n>>>>>>>> \n>>>>>>>> 1) at config stage, create a random number for the build\n>>>>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n>>>>>>>> function, compare the generated random number for allowing the\n>>>>>>>> calls to make within the library. i.e leverage the fact that\n>>>>>>>> external library would never know the random number generated\n>>>>>>>> for the DPDK build\n>>>>>> and internal driver code does.\n>>>>>>>> \n>>>>>>> Do we really need to care about this. If have some determined\n>>>>>>> enough to hack around our limitations, then they surely know that\n>>>>>>> they have an unsupported configuration. We just need to protect\n>>>>>>> against inadvertent use of internals, IMHO.\n>>>>>>> \n>>>>>> I agree, I too had thought about doing some sort of internal runtime\n>>>>>> checking to match internal only symbols, such that they were only\n>>>>>> accessable by internally approved users, but it started to feel like a great\n>>>> deal of overhead.\n>>>>>> Its a good idea for a general mechanism I think, but I believe the\n>>>>>> value here is more to internally document which apis we want to mark\n>>>>>> as being for internal use only, and create a lightweight roadblock\n>>>>>> at build time to catch users inadvertently using them. Determined\n>>>>>> users will get around anything, and theres not much we can do to stop\n>>>> them.\n>>>>> \n>>>>> I agree too. IMHO, Simply having following items would be enough\n>>>>> \n>>>>> 1) Avoid exposing the internal function prototype through public\n>>>>> header files\n>>>>> 2) Add @internal to API documentation\n>>>>> 3) Just decide the name space for internal API for tooling(i.e not\n>>>>> start with rte_ or so) Using objdump scheme to detect internal functions\n>>>> requires the the library to build prior to run the checkpatch.\n>>>>> \n>>>> \n>>>> No, I'm not comfortable with that approach, and I've stated why:\n>>>> 1) Not exposing the functions via header files is a fine start\n>>>> \n>>>> 2) Adding internal documentation is also fine, but does nothing to correlate\n>>>> the code implementing those functions to the documentation. Its valuable\n>>>> to have a tag on a function identifying it as internal only.\n>>>> \n>>>> 3) Using naming conventions to separate internal only from non-internal\n>>>> functions is a vague approach, requiring future developers to be cogniscent\n>>>> of the convention and make the appropriate naming choices. It also implicitly\n>>>> restricts the abliity for future developers to make naming changes in conflict\n>>>> with that convention\n>>> \n>>> Enforcing the naming convention can be achieved through tooling as well.\n>>> \n>>>> \n>>>> 4) Adding a tag like __rte_internal creates an interlock whereby, not only are\n>>>> internal functions excused from ABI constraints, but forces developers to\n>>>> intentionally mark their internal functions as being internal in the code, which\n>>>> is beneficial to clarlity of understanding during the development process.\n>>> \n>>> No issues in adding __rte_internal. But, I am against current implementaion, \n>>> Ie. adding objdump dependency\n>>> to checkpatch i.e developer has to build the library first so that checkpatch can\n>>> can know, Is it belongs to internal section or not?\n>>> \n>>>> \n>>>> 5) Adding a tag like __rte_internal is explicit, and allows developers to use a\n>>>> single header file instead of multiple header files if they so choose\n>>>> \n>>>> We went through this with experimental symbols as well[1], and it just\n>>>> makes more sense to me to clearly document in the code what constitutes\n>>>> an internal symbol rather than relying on naming conventions and hoping\n>>>> that developers read the documentation before exporting a symbol\n>>>> publically.\n>> \n>> I feel like we are creating a lot of extra work for the developer and adding a number of constraints to getting code patches submitted as the tools all have to be working together. The versioning file and __rte_experimental stuff today has always being handle wrong or not done by the developer. Altering the tools to detect these changes works and it seemed to take a while to iron out. To me we should be doing the minimum steps to reasonably isolate internal API and data from the user. If someone wants to access the those APIs that is their choice and enforcing with new macros and tools is over kill IMHO.\n>> \n>> 1) Adding @internal to documentation is a great start along with more docs to explain what internal functions/data should be handled.\n> I've got no issue with this\n>> 2) Hiding/moving internal function prototypes in private headers.\n> Nor this, though if you want to do it, ensuring that every library has a private\n> header that doesn't get exported has to be part of the review process, and I'm\n> not confident that that will be a focus of anyones review\n> \n>> 3) Adding setters/getters for internal data.\n> Sure, no issue here\n>> 4) Make sure we review and reject direct use of internal functions and data.\n> How exactly do you intend to enforce this? By definition, the use of internal\n> functions is restricted only to dpdk core libraries, and those are the only\n> patches we ever see on the list. This change is meant to enforce usage\n> prevention for users writing applications whos patches will never be seen for\n> review (save for our example programs)\n> \n> We already have this mechanism available for experimental abi, and from my\n> perspective it works quite well, and is fairly well understood. I don't see\n> whats wrong with expanding that mechanism to internal functions.\n\nOn this case I was talking more about accessing internal data directly instead of using getters/setters.\n\nI understand your other points, but if we use the items above it should solve most of the issues. Adding another tag and then adding tools to make it work is just going a bit too far. The reason that experimental works is normally the developer only has a few APIs to mark and it works along with versioning you added. The versioning and experimental parts are kind of a requirement with shared libs and identifying experimental APIs. In the case of marking all of the APIs as internal could be a huge list for all of the libs, we should move them to private headers instead.\n> \n> Neil\n> \n>> \n>> The goal here is to handle the 80% rule and make it very obvious to the developer these are internal functions and data. Using these or similar minimum steps should be reasonable IMHO.\n>>>> \n>>>> \n>>>> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n>>>>>> \n>>>>>> If we really wanted to go down that road, we could use a mechainsm\n>>>>>> simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure\n>>>>>> that the kernel uses, but that would required building our own\n>>>>>> custom linker script, which seems like overkill here.\n>>>>>> \n>>>>>> Best\n>>>>>> Neil\n>>>>>> \n>>>>>>> /Bruce\n>> \n>> Regards,\n>> Keith\n\nRegards,\nKeith", "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 32B331B95A;\n\tThu, 6 Jun 2019 15:53:51 +0200 (CEST)", "from mga18.intel.com (mga18.intel.com [134.134.136.126])\n\tby dpdk.org (Postfix) with ESMTP id A8B4E1B959\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 15:53:49 +0200 (CEST)", "from fmsmga006.fm.intel.com ([10.253.24.20])\n\tby orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t06 Jun 2019 06:53:48 -0700", "from fmsmsx103.amr.corp.intel.com ([10.18.124.201])\n\tby fmsmga006.fm.intel.com with ESMTP; 06 Jun 2019 06:53:48 -0700", "from fmsmsx126.amr.corp.intel.com (10.18.125.43) by\n\tFMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP\n\tServer (TLS) id 14.3.408.0; Thu, 6 Jun 2019 06:53:48 -0700", "from fmsmsx117.amr.corp.intel.com ([169.254.3.141]) by\n\tFMSMSX126.amr.corp.intel.com ([169.254.1.74]) with mapi id\n\t14.03.0415.000; Thu, 6 Jun 2019 06:53:48 -0700" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "From": "\"Wiles, Keith\" <keith.wiles@intel.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "CC": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"dev@dpdk.org\" <dev@dpdk.org>,\n\tThomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVHGAeTHy0x+iqgUew6BEqMONpAqaPEUAAgAAG2wCAAAMCAA==", "Date": "Thu, 6 Jun 2019 13:53:47 +0000", "Message-ID": "<AF2ECFBD-F3B6-4580-86B7-F93BDB7FB34B@intel.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com>\n\t<20190606134300.GC29521@hmswarspite.think-freely.org>", "In-Reply-To": "<20190606134300.GC29521@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[10.255.75.4]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-ID": "<9C29CE9A38D9F94D9659F5706838A77C@intel.com>", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96864, "web_url": "http://patches.dpdk.org/comment/96864/", "msgid": "<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-06T14:02:03", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Thursday, June 6, 2019 7:05 PM\n> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> Thomas Monjalon <thomas@monjalon.net>\n> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> On Thu, Jun 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > -----Original Message-----\n> > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > Sent: Thursday, June 6, 2019 5:04 PM\n> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > > Thomas Monjalon <thomas@monjalon.net>\n> > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > >\n> > > On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran\n> wrote:\n> > > > > -----Original Message-----\n> > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > Sent: Wednesday, June 5, 2019 11:41 PM\n> > > > > To: Bruce Richardson <bruce.richardson@intel.com>\n> > > > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;\n> > > > > dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>\n> > > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > > >\n> > > > > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> > > > > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> > > > > > Kollanukkaran\n> > > > > wrote:\n> > > > > > > > -----Original Message-----\n> > > > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > > > > > To: dev@dpdk.org\n> > > > > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> > > > > > > > Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> > > > > > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > > > > > <thomas@monjalon.net>\n> > > > > > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal\n> > > > > > > > tag\n> > > > > > > >\n> > > > > > > > Hey-\n> > > > > > > > \tBased on our recent conversations regarding the use of\n> > > > > > > > symbols only meant for internal dpdk consumption (between\n> > > > > > > > dpdk libraries), this is an idea that I've come up with\n> > > > > > > > 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\n> > > > > > > > between DPDK libraries, but not by applications linking to\n> > > > > > > > them\n> > > > > > > > 2) We would like to document those symbols in the code, so\n> > > > > > > > as to note them clearly as for being meant for internal\n> > > > > > > > use only\n> > > > > > > > 3) Linker symbol visibility is a very coarse grained tool,\n> > > > > > > > and so there is no good way in a single library to mark\n> > > > > > > > items as being meant for use only by other DPDK libraries,\n> > > > > > > > at least not without some extensive runtime checking\n> > > > > > > >\n> > > > > > > >\n> > > > > > > > Proposal:\n> > > > > > > > I'm proposing that we introduce the __rte_internal tag.\n> > > > > > > > From a coding standpoint it works a great deal like the\n> > > > > > > > __rte_experimental tag in that it expempts the tagged\n> > > > > > > > symbol from ABI constraints (as the only users should be\n> > > > > > > > represented in the DPDK build environment). Additionally,\n> > > > > > > > the __rte_internal macro resolves differently based on the\n> > > > > > > > definition of the BUILDING_RTE_SDK flag (working under the\n> > > > > > > > assumption that said flag should only ever be set if we\n> > > > > > > > are actually building DPDK libraries which will make use\n> > > > > > > > of internal calls). If the BUILDING_RTE_SDK flag is set\n> > > > > > > > __rte_internal resolves to __attribute__((section\n> > > > > > > > \"text.internal)), placing it in a special text section\n> > > > > > > > which is then used to validate that the the symbol appears\n> > > > > > > > in the INTERNAL section of the corresponding library version\n> map).\n> > > > > > > > If BUILDING_RTE_SDK is not set, then __rte_internal\n> > > > > > > > resolves to\n> > > > > __attribute__((error(\"...\"))), which causes any caller of the\n> > > > > tagged function to throw an error at compile time, indicating\n> > > > > that the symbol is not available for external use.\n> > > > > > > >\n> > > > > > > > This isn't a perfect solution, as applications can still\n> > > > > > > > hack around it of course,\n> > > > > > >\n> > > > > > > I think, one way to, avoid, hack around could be to,\n> > > > > > >\n> > > > > > > 1) at config stage, create a random number for the build\n> > > > > > > 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> > > > > > > function, compare the generated random number for allowing\n> > > > > > > the calls to make within the library. i.e leverage the fact\n> > > > > > > that external library would never know the random number\n> > > > > > > generated for the DPDK build\n> > > > > and internal driver code does.\n> > > > > > >\n> > > > > > Do we really need to care about this. If have some determined\n> > > > > > enough to hack around our limitations, then they surely know\n> > > > > > that they have an unsupported configuration. We just need to\n> > > > > > protect against inadvertent use of internals, IMHO.\n> > > > > >\n> > > > > I agree, I too had thought about doing some sort of internal\n> > > > > runtime checking to match internal only symbols, such that they\n> > > > > were only accessable by internally approved users, but it\n> > > > > started to feel like a great\n> > > deal of overhead.\n> > > > > Its a good idea for a general mechanism I think, but I believe\n> > > > > the value here is more to internally document which apis we want\n> > > > > to mark as being for internal use only, and create a lightweight\n> > > > > roadblock at build time to catch users inadvertently using them.\n> > > > > Determined users will get around anything, and theres not much\n> > > > > we can do to stop\n> > > them.\n> > > >\n> > > > I agree too. IMHO, Simply having following items would be enough\n> > > >\n> > > > 1) Avoid exposing the internal function prototype through public\n> > > > header files\n> > > > 2) Add @internal to API documentation\n> > > > 3) Just decide the name space for internal API for tooling(i.e not\n> > > > start with rte_ or so) Using objdump scheme to detect internal\n> > > > functions\n> > > requires the the library to build prior to run the checkpatch.\n> > > >\n> > >\n> > > No, I'm not comfortable with that approach, and I've stated why:\n> > > 1) Not exposing the functions via header files is a fine start\n> > >\n> > > 2) Adding internal documentation is also fine, but does nothing to\n> > > correlate the code implementing those functions to the\n> > > documentation. Its valuable to have a tag on a function identifying it as\n> internal only.\n> > >\n> > > 3) Using naming conventions to separate internal only from\n> > > non-internal functions is a vague approach, requiring future\n> > > developers to be cogniscent of the convention and make the\n> > > appropriate naming choices. It also implicitly restricts the\n> > > abliity for future developers to make naming changes in conflict\n> > > with that convention\n> >\n> > Enforcing the naming convention can be achieved through tooling as well.\n> >\n> Sure, but why enforce any function naming at all, when you don't have to.\n\nMay I ask, why to enforce __rte_internal, when you don't have to\n\n> \n> > >\n> > > 4) Adding a tag like __rte_internal creates an interlock whereby,\n> > > not only are internal functions excused from ABI constraints, but\n> > > forces developers to intentionally mark their internal functions as\n> > > being internal in the code, which is beneficial to clarlity of understanding\n> during the development process.\n> >\n> > No issues in adding __rte_internal. But, I am against current\n> > implementaion, Ie. adding objdump dependency\n> That dependency already exists for the __rte_external flag\n\nSorry, I could not see the dependency.\n\n[master][dpdk.org] $ grep -ri \"objdump\" devtools/\n[master][dpdk.org] $ grep -ri \"objdump\" usertools/\n[master][dpdk.org] $ grep -ri \"__rte_external\" *\n\n> \n> > to checkpatch i.e developer has to build the library first so that\n> > checkpatch can can know, Is it belongs to internal section or not?\n> >\n> What developer is running checkpatch/posting patches without first building\n> their changes?\n\n# it is not developer, The CI/CD tools can quicky check the sanity of patches\nbefore the build itself. Why to add unnecessary dependency?\n# If some PMD is not building if the requirements are not meet(say AES NI PMD for crypto)\nthen how do take care of the dependency.\n\n\n> \n> \n> > >\n> > > 5) Adding a tag like __rte_internal is explicit, and allows\n> > > developers to use a single header file instead of multiple header\n> > > files if they so choose\n> > >\n> > > We went through this with experimental symbols as well[1], and it\n> > > just makes more sense to me to clearly document in the code what\n> > > constitutes an internal symbol rather than relying on naming\n> > > conventions and hoping that developers read the documentation before\n> > > exporting a symbol publically.\n> > >\n> > >\n> > > [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> > > > >\n> > > > > If we really wanted to go down that road, we could use a\n> > > > > mechainsm simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL\n> > > > > infrastructure that the kernel uses, but that would required\n> > > > > building our own custom linker script, which seems like overkill here.\n> > > > >\n> > > > > Best\n> > > > > Neil\n> > > > >\n> > > > > > /Bruce\n> > > > > >\n> > > >\n> >", "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 90CC81B95A;\n\tThu, 6 Jun 2019 16:02:14 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com\n\t[67.231.156.173]) by dpdk.org (Postfix) with ESMTP id DF4551B959\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 16:02:12 +0200 (CEST)", "from pps.filterd (m0045851.ppops.net [127.0.0.1])\n\tby mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx56DtFXV025026; Thu, 6 Jun 2019 07:02:12 -0700", "from sc-exch02.marvell.com ([199.233.58.182])\n\tby mx0b-0016f401.pphosted.com with ESMTP id 2sxthej3gb-2\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tThu, 06 Jun 2019 07:02:11 -0700", "from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH02.marvell.com\n\t(10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tThu, 6 Jun 2019 07:02:09 -0700", "from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.59)\n\tby SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 07:02:09 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2581.namprd18.prod.outlook.com (20.179.93.210) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1965.14; Thu, 6 Jun 2019 14:02:03 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tThu, 6 Jun 2019 14:02:03 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=LBnFB30OC37sXMFoEeni7MEL5DJ4ttSCorBSCeN2He4=;\n\tb=sU7sSeM/MbJWuIlaATqRddjSH5rPzowVsd3HXqAXa0obwze2Jh4VpUDiNiAoBTiAnH0k\n\tsGby+GzLt+UT7aOLaCJf4oVE32XiH7ziPKUfOhym/Fza+r2rS1bDIVAnG1BNLcUr0IJI\n\tQZFYTuxQBMnl5FLALxurgQcEvReneM9vUZo6fRMwFQE03ZxHakkZKeHoS6+DecsI65iV\n\tVWU4pfWPUFoVwdNnRVwe1I2/E5tIWXhSVYZB2uWy+tD6wW5e7NmI+wA6UUw9xOdkxegE\n\t+mobNPd4qusnoJxwrPzyWm0giQ7oVCG/kHlTHQnhyTGPWkwNl8VwfNOTE7XWQesX2mmD\n\tJA== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=LBnFB30OC37sXMFoEeni7MEL5DJ4ttSCorBSCeN2He4=;\n\tb=P0nDsN4Zn7il8Vrnv5rOAY+QZhML1wkQVPUeDzerxR4W1eJD+inSUFo/6yAb+LR53z20BVoRNO126Ecgv7hIj6O72AKEIOKA50AhUGwUkafFtkwg3Y86I9n+jwY+PU5jSH0TBCarjkRcQ34jMbzgtSu38+0O1vbT5LmzI9ovJ0A=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "CC": "Bruce Richardson <bruce.richardson@intel.com>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyAgAAgfgCAAAaRkIAAGyeAgAAFlPA=", "Date": "Thu, 6 Jun 2019 14:02:03 +0000", "Message-ID": "<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>", "In-Reply-To": "<20190606133503.GB29521@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[122.178.234.223]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "0779ada5-298f-48eb-f0be-08d6ea878d7f", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2581; ", "x-ms-traffictypediagnostic": "BYAPR18MB2581:", "x-ms-exchange-purlcount": "1", "x-microsoft-antispam-prvs": "<BYAPR18MB258100488FB75BFB91004BEFC8170@BYAPR18MB2581.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-forefront-prvs": "00603B7EEF", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(136003)(396003)(376002)(39860400002)(346002)(366004)(199004)(189003)(174874002)(13464003)(43544003)(68736007)(11346002)(73956011)(66946007)(26005)(86362001)(64756008)(76116006)(66446008)(66556008)(66476007)(76176011)(74316002)(55016002)(446003)(25786009)(478600001)(316002)(66066001)(186003)(6116002)(8936002)(3846002)(52536014)(5660300002)(33656002)(966005)(71200400001)(71190400001)(99286004)(9686003)(53936002)(81166006)(81156014)(7696005)(14444005)(256004)(53546011)(14454004)(6916009)(486006)(8676002)(305945005)(4326008)(54906003)(6506007)(6246003)(6306002)(229853002)(6436002)(102836004)(476003)(2906002)(561944003)(7736002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2581;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; A:1; MX:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "w6GO52Ltu9aUvjJGHZDAYgu6okXFCkR7rHdgrCVm1ONuQ+IKqgxxzKeGXyjra0QmdV7gIaMkdtoB1ybO64SlYf9gGjmzRrNUDbuz2Lufsp/BPmUxjnMbFTUGzAUUf+9HbGa1bXs3/YPBUN/+dkwTVw5tdcBC7F/T7A7Duan/4/mBw24njtpw6NpSLdwzWy27LC9vfn+Os4WYF6/qefYmLjfOtz9oRaW2yp63LoY+xKVpA1MldrmInrkV0hMN/jO/UDAXNNS+7Mn9qkzYrVPXI7GYQ/XfjvYxZiL4gUprE6UOxwAHqxN5obbH3oQHjXOoAfF3Y+Qgt/FPUL1ZbTnkE+WzfB/xyjGH8d7WBz8QQ1oVyEXAJqiw//eLtE67tHJxCNXpMrWqHlAUKa1bhI4gTmG/ts0NzNXA6ZwcXdFDK4U=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "0779ada5-298f-48eb-f0be-08d6ea878d7f", "X-MS-Exchange-CrossTenant-originalarrivaltime": "06 Jun 2019 14:02:03.2891\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2581", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-06_10:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96869, "web_url": "http://patches.dpdk.org/comment/96869/", "msgid": "<20190606144625.GE29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606144625.GE29521@hmswarspite.think-freely.org", "date": "2019-06-06T14:46:25", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 01:53:47PM +0000, Wiles, Keith wrote:\n> \n> \n> > On Jun 6, 2019, at 8:43 AM, Neil Horman <nhorman@tuxdriver.com> wrote:\n> > \n> > On Thu, Jun 06, 2019 at 01:18:29PM +0000, Wiles, Keith wrote:\n> >> \n> >> \n> >>> On Jun 6, 2019, at 7:04 AM, Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:\n> >>> \n> >>>> -----Original Message-----\n> >>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>> Sent: Thursday, June 6, 2019 5:04 PM\n> >>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> >>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> >>>> Thomas Monjalon <thomas@monjalon.net>\n> >>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>> \n> >>>> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran wrote:\n> >>>>>> -----Original Message-----\n> >>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>>>> Sent: Wednesday, June 5, 2019 11:41 PM\n> >>>>>> To: Bruce Richardson <bruce.richardson@intel.com>\n> >>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org;\n> >>>>>> Thomas Monjalon <thomas@monjalon.net>\n> >>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>>>> \n> >>>>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> >>>>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> >>>>>>> Kollanukkaran\n> >>>>>> wrote:\n> >>>>>>>>> -----Original Message-----\n> >>>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n> >>>>>>>>> To: dev@dpdk.org\n> >>>>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> >>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> >>>>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n> >>>>>>>>> <thomas@monjalon.net>\n> >>>>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>>>>>>> \n> >>>>>>>>> Hey-\n> >>>>>>>>> \tBased on our recent conversations regarding the use of\n> >>>>>>>>> symbols only meant for internal dpdk consumption (between dpdk\n> >>>>>>>>> libraries), this is an idea that I've come up with that I'd\n> >>>>>>>>> like to get some feedback on\n> >>>>>>>>> \n> >>>>>>>>> Summary:\n> >>>>>>>>> 1) We have symbols in the DPDK that are meant to be used\n> >>>>>>>>> between DPDK libraries, but not by applications linking to\n> >>>>>>>>> them\n> >>>>>>>>> 2) We would like to document those symbols in the code, so as\n> >>>>>>>>> to note them clearly as for being meant for internal use only\n> >>>>>>>>> 3) Linker symbol visibility is a very coarse grained tool, and\n> >>>>>>>>> so there is no good way in a single library to mark items as\n> >>>>>>>>> being meant for use only by other DPDK libraries, at least not\n> >>>>>>>>> without some extensive runtime checking\n> >>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>> Proposal:\n> >>>>>>>>> I'm proposing that we introduce the __rte_internal tag. From\n> >>>>>>>>> a coding standpoint it works a great deal like the\n> >>>>>>>>> __rte_experimental tag in that it expempts the tagged symbol\n> >>>>>>>>> from ABI constraints (as the only users should be represented\n> >>>>>>>>> in the DPDK build environment). Additionally, the\n> >>>>>>>>> __rte_internal macro resolves differently based on the\n> >>>>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n> >>>>>>>>> assumption that said flag should only ever be set if we are\n> >>>>>>>>> actually building DPDK libraries which will make use of\n> >>>>>>>>> internal calls). If the BUILDING_RTE_SDK flag is set\n> >>>>>>>>> __rte_internal resolves to __attribute__((section\n> >>>>>>>>> \"text.internal)), placing it in a special text section which\n> >>>>>>>>> is then used to validate that the the symbol appears in the\n> >>>>>>>>> INTERNAL section of the corresponding library version map).\n> >>>>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal resolves\n> >>>>>>>>> to\n> >>>>>> __attribute__((error(\"...\"))), which causes any caller of the tagged\n> >>>>>> function to throw an error at compile time, indicating that the\n> >>>>>> symbol is not available for external use.\n> >>>>>>>>> \n> >>>>>>>>> This isn't a perfect solution, as applications can still hack\n> >>>>>>>>> around it of course,\n> >>>>>>>> \n> >>>>>>>> I think, one way to, avoid, hack around could be to,\n> >>>>>>>> \n> >>>>>>>> 1) at config stage, create a random number for the build\n> >>>>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> >>>>>>>> function, compare the generated random number for allowing the\n> >>>>>>>> calls to make within the library. i.e leverage the fact that\n> >>>>>>>> external library would never know the random number generated\n> >>>>>>>> for the DPDK build\n> >>>>>> and internal driver code does.\n> >>>>>>>> \n> >>>>>>> Do we really need to care about this. If have some determined\n> >>>>>>> enough to hack around our limitations, then they surely know that\n> >>>>>>> they have an unsupported configuration. We just need to protect\n> >>>>>>> against inadvertent use of internals, IMHO.\n> >>>>>>> \n> >>>>>> I agree, I too had thought about doing some sort of internal runtime\n> >>>>>> checking to match internal only symbols, such that they were only\n> >>>>>> accessable by internally approved users, but it started to feel like a great\n> >>>> deal of overhead.\n> >>>>>> Its a good idea for a general mechanism I think, but I believe the\n> >>>>>> value here is more to internally document which apis we want to mark\n> >>>>>> as being for internal use only, and create a lightweight roadblock\n> >>>>>> at build time to catch users inadvertently using them. Determined\n> >>>>>> users will get around anything, and theres not much we can do to stop\n> >>>> them.\n> >>>>> \n> >>>>> I agree too. IMHO, Simply having following items would be enough\n> >>>>> \n> >>>>> 1) Avoid exposing the internal function prototype through public\n> >>>>> header files\n> >>>>> 2) Add @internal to API documentation\n> >>>>> 3) Just decide the name space for internal API for tooling(i.e not\n> >>>>> start with rte_ or so) Using objdump scheme to detect internal functions\n> >>>> requires the the library to build prior to run the checkpatch.\n> >>>>> \n> >>>> \n> >>>> No, I'm not comfortable with that approach, and I've stated why:\n> >>>> 1) Not exposing the functions via header files is a fine start\n> >>>> \n> >>>> 2) Adding internal documentation is also fine, but does nothing to correlate\n> >>>> the code implementing those functions to the documentation. Its valuable\n> >>>> to have a tag on a function identifying it as internal only.\n> >>>> \n> >>>> 3) Using naming conventions to separate internal only from non-internal\n> >>>> functions is a vague approach, requiring future developers to be cogniscent\n> >>>> of the convention and make the appropriate naming choices. It also implicitly\n> >>>> restricts the abliity for future developers to make naming changes in conflict\n> >>>> with that convention\n> >>> \n> >>> Enforcing the naming convention can be achieved through tooling as well.\n> >>> \n> >>>> \n> >>>> 4) Adding a tag like __rte_internal creates an interlock whereby, not only are\n> >>>> internal functions excused from ABI constraints, but forces developers to\n> >>>> intentionally mark their internal functions as being internal in the code, which\n> >>>> is beneficial to clarlity of understanding during the development process.\n> >>> \n> >>> No issues in adding __rte_internal. But, I am against current implementaion, \n> >>> Ie. adding objdump dependency\n> >>> to checkpatch i.e developer has to build the library first so that checkpatch can\n> >>> can know, Is it belongs to internal section or not?\n> >>> \n> >>>> \n> >>>> 5) Adding a tag like __rte_internal is explicit, and allows developers to use a\n> >>>> single header file instead of multiple header files if they so choose\n> >>>> \n> >>>> We went through this with experimental symbols as well[1], and it just\n> >>>> makes more sense to me to clearly document in the code what constitutes\n> >>>> an internal symbol rather than relying on naming conventions and hoping\n> >>>> that developers read the documentation before exporting a symbol\n> >>>> publically.\n> >> \n> >> I feel like we are creating a lot of extra work for the developer and adding a number of constraints to getting code patches submitted as the tools all have to be working together. The versioning file and __rte_experimental stuff today has always being handle wrong or not done by the developer. Altering the tools to detect these changes works and it seemed to take a while to iron out. To me we should be doing the minimum steps to reasonably isolate internal API and data from the user. If someone wants to access the those APIs that is their choice and enforcing with new macros and tools is over kill IMHO.\n> >> \n> >> 1) Adding @internal to documentation is a great start along with more docs to explain what internal functions/data should be handled.\n> > I've got no issue with this\n> >> 2) Hiding/moving internal function prototypes in private headers.\n> > Nor this, though if you want to do it, ensuring that every library has a private\n> > header that doesn't get exported has to be part of the review process, and I'm\n> > not confident that that will be a focus of anyones review\n> > \n> >> 3) Adding setters/getters for internal data.\n> > Sure, no issue here\n> >> 4) Make sure we review and reject direct use of internal functions and data.\n> > How exactly do you intend to enforce this? By definition, the use of internal\n> > functions is restricted only to dpdk core libraries, and those are the only\n> > patches we ever see on the list. This change is meant to enforce usage\n> > prevention for users writing applications whos patches will never be seen for\n> > review (save for our example programs)\n> > \n> > We already have this mechanism available for experimental abi, and from my\n> > perspective it works quite well, and is fairly well understood. I don't see\n> > whats wrong with expanding that mechanism to internal functions.\n> \n> On this case I was talking more about accessing internal data directly instead of using getters/setters.\n> \nSure, we want to prevent that, but the linker version map should prevent it by\nnot exporting those globals already, meaning we're required to implement getters\nand setters. You can get around that of course by adding a global variable to\nthe linker map file, but thats strongly discouraged.\n\n> I understand your other points, but if we use the items above it should solve most of the issues. Adding another tag and then adding tools to make it work is just going a bit too far. The reason that experimental works is normally the developer only has a few APIs to mark and it works along with versioning you added. The versioning and experimental parts are kind of a requirement with shared libs and identifying experimental APIs. In the case of marking all of the APIs as internal could be a huge list for all of the libs, we should move them to private headers instead.\nWe're not adding tools, we're modifying existing tools to make this work. \n\nIf you're concerned about the added onus of tagging internal only functions, I\nwouldn't be opposed to adding tooling to automatically document functions marked\nwith __rte_internal with @internal in the documentation tree, so that the\noverhead is no larger than what we expect now (documenting @internal in the docs\ndirectly)\n\nAs for the effort to tag functions as internal only, I think we might disagree\non what the size of the internal-only api is. If we start with Jerins\nassumption that all internal functions do not start with rte_, then a quick scan\nof the version maps in the dpdk suggests there are currently 266 functions that\nwe would consider to be internal only. Of those 266 a little less than half are\nalready addressed by the RFC patch I sent. Getting the rest under tagged as\n__rte_internal is about a days worth of work. From there its just standard\nmaintenence.\n\nNeil\n\n> > \n> > Neil\n> > \n> >> \n> >> The goal here is to handle the 80% rule and make it very obvious to the developer these are internal functions and data. Using these or similar minimum steps should be reasonable IMHO.\n> >>>> \n> >>>> \n> >>>> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> >>>>>> \n> >>>>>> If we really wanted to go down that road, we could use a mechainsm\n> >>>>>> simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure\n> >>>>>> that the kernel uses, but that would required building our own\n> >>>>>> custom linker script, which seems like overkill here.\n> >>>>>> \n> >>>>>> Best\n> >>>>>> Neil\n> >>>>>> \n> >>>>>>> /Bruce\n> >> \n> >> Regards,\n> >> Keith\n> \n> Regards,\n> Keith\n> \n>", "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 4415B1B95B;\n\tThu, 6 Jun 2019 16:47:05 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id 3D87A1B959\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 16:47:03 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYtfI-0003lu-P0; Thu, 06 Jun 2019 10:46:57 -0400" ], "Date": "Thu, 6 Jun 2019 10:46:25 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "\"Wiles, Keith\" <keith.wiles@intel.com>", "Cc": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>,\n\t\"Richardson, Bruce\" <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606144625.GE29521@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<015190E6-5703-40E2-9CBE-DAB3DA74669B@intel.com>\n\t<20190606134300.GC29521@hmswarspite.think-freely.org>\n\t<AF2ECFBD-F3B6-4580-86B7-F93BDB7FB34B@intel.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<AF2ECFBD-F3B6-4580-86B7-F93BDB7FB34B@intel.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96871, "web_url": "http://patches.dpdk.org/comment/96871/", "msgid": "<20190606150354.GF29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606150354.GF29521@hmswarspite.think-freely.org", "date": "2019-06-06T15:03:54", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 02:02:03PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > -----Original Message-----\n> > From: Neil Horman <nhorman@tuxdriver.com>\n> > Sent: Thursday, June 6, 2019 7:05 PM\n> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > Thomas Monjalon <thomas@monjalon.net>\n> > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > \n> > On Thu, Jun 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > > -----Original Message-----\n> > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > Sent: Thursday, June 6, 2019 5:04 PM\n> > > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > > > Thomas Monjalon <thomas@monjalon.net>\n> > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > >\n> > > > On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran\n> > wrote:\n> > > > > > -----Original Message-----\n> > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > Sent: Wednesday, June 5, 2019 11:41 PM\n> > > > > > To: Bruce Richardson <bruce.richardson@intel.com>\n> > > > > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;\n> > > > > > dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>\n> > > > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > > > >\n> > > > > > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> > > > > > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> > > > > > > Kollanukkaran\n> > > > > > wrote:\n> > > > > > > > > -----Original Message-----\n> > > > > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > > > > > > To: dev@dpdk.org\n> > > > > > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> > > > > > > > > Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> > > > > > > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > > > > > > <thomas@monjalon.net>\n> > > > > > > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal\n> > > > > > > > > tag\n> > > > > > > > >\n> > > > > > > > > Hey-\n> > > > > > > > > \tBased on our recent conversations regarding the use of\n> > > > > > > > > symbols only meant for internal dpdk consumption (between\n> > > > > > > > > dpdk libraries), this is an idea that I've come up with\n> > > > > > > > > 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\n> > > > > > > > > between DPDK libraries, but not by applications linking to\n> > > > > > > > > them\n> > > > > > > > > 2) We would like to document those symbols in the code, so\n> > > > > > > > > as to note them clearly as for being meant for internal\n> > > > > > > > > use only\n> > > > > > > > > 3) Linker symbol visibility is a very coarse grained tool,\n> > > > > > > > > and so there is no good way in a single library to mark\n> > > > > > > > > items as being meant for use only by other DPDK libraries,\n> > > > > > > > > at least not without some extensive runtime checking\n> > > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Proposal:\n> > > > > > > > > I'm proposing that we introduce the __rte_internal tag.\n> > > > > > > > > From a coding standpoint it works a great deal like the\n> > > > > > > > > __rte_experimental tag in that it expempts the tagged\n> > > > > > > > > symbol from ABI constraints (as the only users should be\n> > > > > > > > > represented in the DPDK build environment). Additionally,\n> > > > > > > > > the __rte_internal macro resolves differently based on the\n> > > > > > > > > definition of the BUILDING_RTE_SDK flag (working under the\n> > > > > > > > > assumption that said flag should only ever be set if we\n> > > > > > > > > are actually building DPDK libraries which will make use\n> > > > > > > > > of internal calls). If the BUILDING_RTE_SDK flag is set\n> > > > > > > > > __rte_internal resolves to __attribute__((section\n> > > > > > > > > \"text.internal)), placing it in a special text section\n> > > > > > > > > which is then used to validate that the the symbol appears\n> > > > > > > > > in the INTERNAL section of the corresponding library version\n> > map).\n> > > > > > > > > If BUILDING_RTE_SDK is not set, then __rte_internal\n> > > > > > > > > resolves to\n> > > > > > __attribute__((error(\"...\"))), which causes any caller of the\n> > > > > > tagged function to throw an error at compile time, indicating\n> > > > > > that the symbol is not available for external use.\n> > > > > > > > >\n> > > > > > > > > This isn't a perfect solution, as applications can still\n> > > > > > > > > hack around it of course,\n> > > > > > > >\n> > > > > > > > I think, one way to, avoid, hack around could be to,\n> > > > > > > >\n> > > > > > > > 1) at config stage, create a random number for the build\n> > > > > > > > 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> > > > > > > > function, compare the generated random number for allowing\n> > > > > > > > the calls to make within the library. i.e leverage the fact\n> > > > > > > > that external library would never know the random number\n> > > > > > > > generated for the DPDK build\n> > > > > > and internal driver code does.\n> > > > > > > >\n> > > > > > > Do we really need to care about this. If have some determined\n> > > > > > > enough to hack around our limitations, then they surely know\n> > > > > > > that they have an unsupported configuration. We just need to\n> > > > > > > protect against inadvertent use of internals, IMHO.\n> > > > > > >\n> > > > > > I agree, I too had thought about doing some sort of internal\n> > > > > > runtime checking to match internal only symbols, such that they\n> > > > > > were only accessable by internally approved users, but it\n> > > > > > started to feel like a great\n> > > > deal of overhead.\n> > > > > > Its a good idea for a general mechanism I think, but I believe\n> > > > > > the value here is more to internally document which apis we want\n> > > > > > to mark as being for internal use only, and create a lightweight\n> > > > > > roadblock at build time to catch users inadvertently using them.\n> > > > > > Determined users will get around anything, and theres not much\n> > > > > > we can do to stop\n> > > > them.\n> > > > >\n> > > > > I agree too. IMHO, Simply having following items would be enough\n> > > > >\n> > > > > 1) Avoid exposing the internal function prototype through public\n> > > > > header files\n> > > > > 2) Add @internal to API documentation\n> > > > > 3) Just decide the name space for internal API for tooling(i.e not\n> > > > > start with rte_ or so) Using objdump scheme to detect internal\n> > > > > functions\n> > > > requires the the library to build prior to run the checkpatch.\n> > > > >\n> > > >\n> > > > No, I'm not comfortable with that approach, and I've stated why:\n> > > > 1) Not exposing the functions via header files is a fine start\n> > > >\n> > > > 2) Adding internal documentation is also fine, but does nothing to\n> > > > correlate the code implementing those functions to the\n> > > > documentation. Its valuable to have a tag on a function identifying it as\n> > internal only.\n> > > >\n> > > > 3) Using naming conventions to separate internal only from\n> > > > non-internal functions is a vague approach, requiring future\n> > > > developers to be cogniscent of the convention and make the\n> > > > appropriate naming choices. It also implicitly restricts the\n> > > > abliity for future developers to make naming changes in conflict\n> > > > with that convention\n> > >\n> > > Enforcing the naming convention can be achieved through tooling as well.\n> > >\n> > Sure, but why enforce any function naming at all, when you don't have to.\n> \n> May I ask, why to enforce __rte_internal, when you don't have to\n> \n\nBecause its more clear. Implicitly deciding that any function not prefixed with\nrte_ is internal only does nothing to prevent a developer from accidentally\nnaming a function incorrectly, exporting it, and allowing a user to call it. We\ncan move headers all you want, but we provide an ABI guarantee to end users, and\ndevelopers should have a way to clearly record that without having to check the\ndocumentation for each function that an application developer wants to use.\n\nThe long and the short of it for me is that I want a way for developers to opt\ntheir code into an internal only condition, not to just document it as such\nand hope its up to date. If they tag a function as __rte_internal then its\nclearly marked as internal only, they have checks to ensure that its in the\nINTERNAL section of the version map, and should that header somehow get\nexternally exported (see rte_mempool_check_cookies for an example of how thats\nhappened), users are prevented from using them at build time, rather than having\nto ask questions on the list, or read documentation after an error to find out\n\"oops, shouldn't have done that\".\n\nI think you'll find that going through all the header files, and bifurcating\nthem to public and private headers is a much larger undertaking than just\ntagging those functions accordingly. a quick scan of all our header file for\nthe @internal tag shows about 260 instances of such functions, almost all of\nwhich are published to applications. All of those functions would have to be\nmoved to private headers, and their requisite C files would need to be updated\nto include the new header. with the use of __rte_internal, we just have tag the\nfunctions as such, which can be handled with a cocinelle or awk script.\n\nNeil\n \n\n> > \n> > > >\n> > > > 4) Adding a tag like __rte_internal creates an interlock whereby,\n> > > > not only are internal functions excused from ABI constraints, but\n> > > > forces developers to intentionally mark their internal functions as\n> > > > being internal in the code, which is beneficial to clarlity of understanding\n> > during the development process.\n> > >\n> > > No issues in adding __rte_internal. But, I am against current\n> > > implementaion, Ie. adding objdump dependency\n> > That dependency already exists for the __rte_external flag\n> \n> Sorry, I could not see the dependency.\n> \n> [master][dpdk.org] $ grep -ri \"objdump\" devtools/\n> [master][dpdk.org] $ grep -ri \"objdump\" usertools/\n> [master][dpdk.org] $ grep -ri \"__rte_external\" *\n> \n> > \n> > > to checkpatch i.e developer has to build the library first so that\n> > > checkpatch can can know, Is it belongs to internal section or not?\n> > >\n> > What developer is running checkpatch/posting patches without first building\n> > their changes?\n> \n> # it is not developer, The CI/CD tools can quicky check the sanity of patches\n> before the build itself. Why to add unnecessary dependency?\n> # If some PMD is not building if the requirements are not meet(say AES NI PMD for crypto)\n> then how do take care of the dependency.\n> \n> \n> > \n> > \n> > > >\n> > > > 5) Adding a tag like __rte_internal is explicit, and allows\n> > > > developers to use a single header file instead of multiple header\n> > > > files if they so choose\n> > > >\n> > > > We went through this with experimental symbols as well[1], and it\n> > > > just makes more sense to me to clearly document in the code what\n> > > > constitutes an internal symbol rather than relying on naming\n> > > > conventions and hoping that developers read the documentation before\n> > > > exporting a symbol publically.\n> > > >\n> > > >\n> > > > [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> > > > > >\n> > > > > > If we really wanted to go down that road, we could use a\n> > > > > > mechainsm simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL\n> > > > > > infrastructure that the kernel uses, but that would required\n> > > > > > building our own custom linker script, which seems like overkill here.\n> > > > > >\n> > > > > > Best\n> > > > > > Neil\n> > > > > >\n> > > > > > > /Bruce\n> > > > > > >\n> > > > >\n> > >\n>", "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 002061B959;\n\tThu, 6 Jun 2019 17:04:35 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id ADE2E1B958\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 17:04:33 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYtwD-0003uy-N6; Thu, 06 Jun 2019 11:04:29 -0400" ], "Date": "Thu, 6 Jun 2019 11:03:54 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Bruce Richardson <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606150354.GF29521@hmswarspite.think-freely.org>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96874, "web_url": "http://patches.dpdk.org/comment/96874/", "msgid": "<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-06T15:14:42", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Thursday, June 6, 2019 8:34 PM\n> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> Thomas Monjalon <thomas@monjalon.net>\n> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> On Thu, Jun 06, 2019 at 02:02:03PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > -----Original Message-----\n> > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > Sent: Thursday, June 6, 2019 7:05 PM\n> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > > Thomas Monjalon <thomas@monjalon.net>\n> > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > >\n> > > On Thu, Jun 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran\n> wrote:\n> > > > > -----Original Message-----\n> > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > Sent: Thursday, June 6, 2019 5:04 PM\n> > > > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > > > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > > > > Thomas Monjalon <thomas@monjalon.net>\n> > > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > > >\n> > > > > On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob\n> > > > > Kollanukkaran\n> > > wrote:\n> > > > > > > -----Original Message-----\n> > > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > > Sent: Wednesday, June 5, 2019 11:41 PM\n> > > > > > > To: Bruce Richardson <bruce.richardson@intel.com>\n> > > > > > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;\n> > > > > > > dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>\n> > > > > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal\n> > > > > > > tag\n> > > > > > >\n> > > > > > > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson\n> wrote:\n> > > > > > > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> > > > > > > > Kollanukkaran\n> > > > > > > wrote:\n> > > > > > > > > > -----Original Message-----\n> > > > > > > > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > > > > > > > Sent: Sunday, May 26, 2019 12:14 AM\n> > > > > > > > > > To: dev@dpdk.org\n> > > > > > > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> > > > > > > > > > Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> > > > > > > > > > <bruce.richardson@intel.com>; Thomas Monjalon\n> > > > > > > > > > <thomas@monjalon.net>\n> > > > > > > > > > Subject: [EXT] [RFC PATCH 0/2] introduce\n> > > > > > > > > > __rte_internal tag\n> > > > > > > > > >\n> > > > > > > > > > Hey-\n> > > > > > > > > > \tBased on our recent conversations regarding the use\n> > > > > > > > > > of symbols only meant for internal dpdk consumption\n> > > > > > > > > > (between dpdk libraries), this is an idea that I've\n> > > > > > > > > > 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\n> > > > > > > > > > used between DPDK libraries, but not by applications\n> > > > > > > > > > linking to them\n> > > > > > > > > > 2) We would like to document those symbols in the\n> > > > > > > > > > code, so as to note them clearly as for being meant\n> > > > > > > > > > for internal use only\n> > > > > > > > > > 3) Linker symbol visibility is a very coarse grained\n> > > > > > > > > > tool, and so there is no good way in a single library\n> > > > > > > > > > to mark items as being meant for use only by other\n> > > > > > > > > > DPDK libraries, at least not without some extensive\n> > > > > > > > > > runtime checking\n> > > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > Proposal:\n> > > > > > > > > > I'm proposing that we introduce the __rte_internal tag.\n> > > > > > > > > > From a coding standpoint it works a great deal like\n> > > > > > > > > > the __rte_experimental tag in that it expempts the\n> > > > > > > > > > tagged symbol from ABI constraints (as the only users\n> > > > > > > > > > should be represented in the DPDK build environment).\n> > > > > > > > > > Additionally, the __rte_internal macro resolves\n> > > > > > > > > > differently based on the definition of the\n> > > > > > > > > > BUILDING_RTE_SDK flag (working under the assumption\n> > > > > > > > > > that said flag should only ever be set if we are\n> > > > > > > > > > actually building DPDK libraries which will make use\n> > > > > > > > > > of internal calls). If the BUILDING_RTE_SDK flag is\n> > > > > > > > > > set __rte_internal resolves to __attribute__((section\n> > > > > > > > > > \"text.internal)), placing it in a special text section\n> > > > > > > > > > which is then used to validate that the the symbol\n> > > > > > > > > > appears in the INTERNAL section of the corresponding\n> > > > > > > > > > library version\n> > > map).\n> > > > > > > > > > If BUILDING_RTE_SDK is not set, then __rte_internal\n> > > > > > > > > > resolves to\n> > > > > > > __attribute__((error(\"...\"))), which causes any caller of\n> > > > > > > the tagged function to throw an error at compile time,\n> > > > > > > indicating that the symbol is not available for external use.\n> > > > > > > > > >\n> > > > > > > > > > This isn't a perfect solution, as applications can\n> > > > > > > > > > still hack around it of course,\n> > > > > > > > >\n> > > > > > > > > I think, one way to, avoid, hack around could be to,\n> > > > > > > > >\n> > > > > > > > > 1) at config stage, create a random number for the\n> > > > > > > > > build\n> > > > > > > > > 2) introduce RTE_CALL_INTERNAL macro for calling\n> > > > > > > > > internal function, compare the generated random number\n> > > > > > > > > for allowing the calls to make within the library. i.e\n> > > > > > > > > leverage the fact that external library would never know\n> > > > > > > > > the random number generated for the DPDK build\n> > > > > > > and internal driver code does.\n> > > > > > > > >\n> > > > > > > > Do we really need to care about this. If have some\n> > > > > > > > determined enough to hack around our limitations, then\n> > > > > > > > they surely know that they have an unsupported\n> > > > > > > > configuration. We just need to protect against inadvertent use\n> of internals, IMHO.\n> > > > > > > >\n> > > > > > > I agree, I too had thought about doing some sort of internal\n> > > > > > > runtime checking to match internal only symbols, such that\n> > > > > > > they were only accessable by internally approved users, but\n> > > > > > > it started to feel like a great\n> > > > > deal of overhead.\n> > > > > > > Its a good idea for a general mechanism I think, but I\n> > > > > > > believe the value here is more to internally document which\n> > > > > > > apis we want to mark as being for internal use only, and\n> > > > > > > create a lightweight roadblock at build time to catch users\n> inadvertently using them.\n> > > > > > > Determined users will get around anything, and theres not\n> > > > > > > much we can do to stop\n> > > > > them.\n> > > > > >\n> > > > > > I agree too. IMHO, Simply having following items would be\n> > > > > > enough\n> > > > > >\n> > > > > > 1) Avoid exposing the internal function prototype through\n> > > > > > public header files\n> > > > > > 2) Add @internal to API documentation\n> > > > > > 3) Just decide the name space for internal API for tooling(i.e\n> > > > > > not start with rte_ or so) Using objdump scheme to detect\n> > > > > > internal functions\n> > > > > requires the the library to build prior to run the checkpatch.\n> > > > > >\n> > > > >\n> > > > > No, I'm not comfortable with that approach, and I've stated why:\n> > > > > 1) Not exposing the functions via header files is a fine start\n> > > > >\n> > > > > 2) Adding internal documentation is also fine, but does nothing\n> > > > > to correlate the code implementing those functions to the\n> > > > > documentation. Its valuable to have a tag on a function\n> > > > > identifying it as\n> > > internal only.\n> > > > >\n> > > > > 3) Using naming conventions to separate internal only from\n> > > > > non-internal functions is a vague approach, requiring future\n> > > > > developers to be cogniscent of the convention and make the\n> > > > > appropriate naming choices. It also implicitly restricts the\n> > > > > abliity for future developers to make naming changes in conflict\n> > > > > with that convention\n> > > >\n> > > > Enforcing the naming convention can be achieved through tooling as\n> well.\n> > > >\n> > > Sure, but why enforce any function naming at all, when you don't have\n> to.\n> >\n> > May I ask, why to enforce __rte_internal, when you don't have to\n> >\n> \n> Because its more clear. Implicitly deciding that any function not prefixed with\n> rte_ is internal only does nothing to prevent a developer from accidentally\n> naming a function incorrectly, exporting it, and allowing a user to call it. We\n> can move headers all you want, but we provide an ABI guarantee to end\n> users, and developers should have a way to clearly record that without\n> having to check the documentation for each function that an application\n> developer wants to use.\n> \n> The long and the short of it for me is that I want a way for developers to opt\n> their code into an internal only condition, not to just document it as such and\n> hope its up to date. If they tag a function as __rte_internal then its clearly\n> marked as internal only, they have checks to ensure that its in the INTERNAL\n> section of the version map, and should that header somehow get externally\n> exported (see rte_mempool_check_cookies for an example of how thats\n> happened), users are prevented from using them at build time, rather than\n> having to ask questions on the list, or read documentation after an error to\n> find out \"oops, shouldn't have done that\".\n> \n> I think you'll find that going through all the header files, and bifurcating them\n> to public and private headers is a much larger undertaking than just tagging\n> those functions accordingly. a quick scan of all our header file for the\n> @internal tag shows about 260 instances of such functions, almost all of\n> which are published to applications. All of those functions would have to be\n> moved to private headers, and their requisite C files would need to be\n> updated to include the new header. with the use of __rte_internal, we just\n> have tag the functions as such, which can be handled with a cocinelle or awk\n> script.\n\nI don't have any strong opinion on name prefix vs marking as __rte_internal.\nOr combination of both. I am fine any approach.\n\nI have only strong option on not to induce objdump dependency for checkpatch. \nFor the reason mentioned in http://mails.dpdk.org/archives/dev/2019-June/134160.html.\n\n\n> \n> Neil\n> \n> \n> > >\n> > > > >\n> > > > > 4) Adding a tag like __rte_internal creates an interlock\n> > > > > whereby, not only are internal functions excused from ABI\n> > > > > constraints, but forces developers to intentionally mark their\n> > > > > internal functions as being internal in the code, which is\n> > > > > beneficial to clarlity of understanding\n> > > during the development process.\n> > > >\n> > > > No issues in adding __rte_internal. But, I am against current\n> > > > implementaion, Ie. adding objdump dependency\n> > > That dependency already exists for the __rte_external flag\n> >\n> > Sorry, I could not see the dependency.\n> >\n> > [master][dpdk.org] $ grep -ri \"objdump\" devtools/ [master][dpdk.org] $\n> > grep -ri \"objdump\" usertools/ [master][dpdk.org] $ grep -ri\n> > \"__rte_external\" *\n> >\n> > >\n> > > > to checkpatch i.e developer has to build the library first so\n> > > > that checkpatch can can know, Is it belongs to internal section or not?\n> > > >\n> > > What developer is running checkpatch/posting patches without first\n> > > building their changes?\n> >\n> > # it is not developer, The CI/CD tools can quicky check the sanity of\n> > patches before the build itself. Why to add unnecessary dependency?\n> > # If some PMD is not building if the requirements are not meet(say AES\n> > NI PMD for crypto) then how do take care of the dependency.\n> >\n> >\n> > >\n> > >\n> > > > >\n> > > > > 5) Adding a tag like __rte_internal is explicit, and allows\n> > > > > developers to use a single header file instead of multiple\n> > > > > header files if they so choose\n> > > > >\n> > > > > We went through this with experimental symbols as well[1], and\n> > > > > it just makes more sense to me to clearly document in the code\n> > > > > what constitutes an internal symbol rather than relying on\n> > > > > naming conventions and hoping that developers read the\n> > > > > documentation before exporting a symbol publically.\n> > > > >\n> > > > >\n> > > > > [1]\n> > > > > https://mails.dpdk.org/archives/dev/2017-December/083828.html\n> > > > > > >\n> > > > > > > If we really wanted to go down that road, we could use a\n> > > > > > > mechainsm simmilar to the EXPORT_SYMBOL /\n> EXPORT_SYMBOL_GPL\n> > > > > > > infrastructure that the kernel uses, but that would required\n> > > > > > > building our own custom linker script, which seems like overkill\n> here.\n> > > > > > >\n> > > > > > > Best\n> > > > > > > Neil\n> > > > > > >\n> > > > > > > > /Bruce\n> > > > > > > >\n> > > > > >\n> > > >\n> >", "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 63F7A1B993;\n\tThu, 6 Jun 2019 17:14:50 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com\n\t[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 46E6A1B974\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 17:14:49 +0200 (CEST)", "from pps.filterd (m0045849.ppops.net [127.0.0.1])\n\tby mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx56FBSdV016711; Thu, 6 Jun 2019 08:14:48 -0700", "from sc-exch04.marvell.com ([199.233.58.184])\n\tby mx0a-0016f401.pphosted.com with ESMTP id 2sxwgnsxyj-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tThu, 06 Jun 2019 08:14:48 -0700", "from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH04.marvell.com\n\t(10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tThu, 6 Jun 2019 08:14:47 -0700", "from NAM05-CO1-obe.outbound.protection.outlook.com (104.47.48.51)\n\tby SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 08:14:47 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2648.namprd18.prod.outlook.com (20.179.94.83) with Microsoft\n\tSMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1965.12; Thu, 6 Jun 2019 15:14:43 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tThu, 6 Jun 2019 15:14:43 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=eRYse1Eh0RKd1ooyygPfPjxWqb1F3+86HwCw+ts1LSY=;\n\tb=rL7yPBGU8apAXYhvY6nozR0xobDkLGw0QFKrjdEAc2DSut3lSrdxTvSz/nNyyQL+qoec\n\trN2gZ6ZF/O6V+bUJfRUlHzzCXYGhuLINGUf/ZFKUw/iODSRidO6WoUNWQ83s2RRifJxc\n\t6r+ubAUCIJdf2IbCvL6dLRL4ZH/T3wjJX+Lu5dzghPXRF0f0et78WK6+44J10L+H/Iaq\n\tGjRShcE/Ae7VONZGLQnijVry3SgYj6aJL9x2hwfKGf7bkIsQuk2UUjZdUpEvrlsG9Vay\n\txLtcM1kwzmBkglJtGFnScLxp4FzHrSSXZdus90SZY7o+zIgz+Hp9mP3p8ms1qUmQLd2W\n\tpQ== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=eRYse1Eh0RKd1ooyygPfPjxWqb1F3+86HwCw+ts1LSY=;\n\tb=ouWK/pk7hQnkEUXELNgPSXhSJvQW1h5AfXzfiiyYHMx2PjSfx+2KrKy/2srDrlFWQI849LbjXyf3bCQbSshJTlrvdl0WTx+/ygybhgFoDv0NU4UGBMTdJFXJ4C78GbHfrqMVb2QEs1FDkVxQw/P8y7MjvCfF2B2aIPc1c2zf6x8=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "CC": "Bruce Richardson <bruce.richardson@intel.com>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyAgAAgfgCAAAaRkIAAGyeAgAAFlPCAABM/AIAAAWqg", "Date": "Thu, 6 Jun 2019 15:14:42 +0000", "Message-ID": "<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>", "In-Reply-To": "<20190606150354.GF29521@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[122.178.234.223]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "2dd6804a-40b1-4e46-8aec-08d6ea91b3fd", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2648; ", "x-ms-traffictypediagnostic": "BYAPR18MB2648:", "x-ms-exchange-purlcount": "2", "x-microsoft-antispam-prvs": "<BYAPR18MB2648EE505703D001BA9FA439C8170@BYAPR18MB2648.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-forefront-prvs": "00603B7EEF", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(39860400002)(376002)(346002)(136003)(366004)(396003)(43544003)(174874002)(13464003)(199004)(189003)(73956011)(81166006)(66946007)(14454004)(4326008)(5660300002)(6916009)(8676002)(66066001)(3846002)(7736002)(66556008)(229853002)(446003)(30864003)(74316002)(66476007)(256004)(64756008)(33656002)(305945005)(7696005)(76176011)(99286004)(68736007)(6436002)(14444005)(53546011)(71190400001)(54906003)(8936002)(9686003)(102836004)(6306002)(6506007)(81156014)(186003)(86362001)(6116002)(26005)(52536014)(55016002)(561944003)(66446008)(76116006)(11346002)(476003)(478600001)(2906002)(6246003)(486006)(25786009)(316002)(53936002)(966005)(71200400001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2648;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; A:1; MX:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "m9oXAJBBDHioxFUAiD9FORRJfm/WZIfKVfPnjJlJ1iae68w58RbaFQH9t1rez/XkP5j7yFObjoWYaSVk3d5ZwLJC9nQak4m2ARCRaEY2s5YGaVoj3WkNGVyHPQMNKVZBaZTPtdWJXnxyzEYscwdxxnXQ6lSM/gbp6bsumXofeJE6s+93nqZtff6mUQ3X3n71Xs75G5HdrkxQ0V0b8RQh05Zhmn6wW4X8epDQPhyVfkUI8/r78ONPpP/szj5h+4rUV3kEBqrCe9QtnLlHR5GPh6pcAllReXrqFANEdZ8pb2UZAQbcdxLbTye3Q2olBU7vwo7UDEqsfQoroRsmYcZpxa9el9OUyrsLNcAYfm6bSGOh/lSgLDgohkK+CLKyvbdyTnqJht4hekDZulttmagFNITU4OBBjfzxLY1w/JPn+eE=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "2dd6804a-40b1-4e46-8aec-08d6ea91b3fd", "X-MS-Exchange-CrossTenant-originalarrivaltime": "06 Jun 2019 15:14:42.8290\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2648", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-06_11:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96876, "web_url": "http://patches.dpdk.org/comment/96876/", "msgid": "<20190606152634.GG29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606152634.GG29521@hmswarspite.think-freely.org", "date": "2019-06-06T15:26:34", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 03:14:42PM +0000, Jerin Jacob Kollanukkaran wrote:\n><snip as this is getting long>\n> \n> I don't have any strong opinion on name prefix vs marking as __rte_internal.\n> Or combination of both. I am fine any approach.\n> \n> I have only strong option on not to induce objdump dependency for checkpatch. \n> For the reason mentioned in http://mails.dpdk.org/archives/dev/2019-June/134160.html.\n> \n\nSorry, in my haste I didn't fully adress this in your previous email\n\nI'm really uncertain what you mean by introducing a checkpatch dependency on\nobjdump here. Theres nothing preventing you from running checkpatch before you\nbuild the library. The only thing checkpatch does in dpdk is scan the patches\nfor sytle violations, and for changes in the map file for movement to and from\nthe EXPERIMENTAL section (i.e. no use of objdump).\n\nMy patch modifies check-experimental-syms.sh (adding an objdump scan for\nINTERNAL symbols, and renaming the script to check-special-syms.sh to be more\nmeaningful). That script however, is not run by checkpatch, its run during\ncompilation of the library to ensure that any symbol in a map file is also\ntagged with __rte_internal in the corresponding object). Theres no path from\ncheckpatches to check-experimental-syms.sh\n\nWhat I meant in my last comment was that any dependency on objdump in\ncheck-[experimental|special]-syms.sh already existed prior to this patch.\n\nSo I'm unsure why you think checkpatches has a dependency.\n\nNeil", "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 A086B1B9A7;\n\tThu, 6 Jun 2019 17:27:14 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id 27E261B9A5\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 17:27:13 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYuIE-00047M-6y; Thu, 06 Jun 2019 11:27:08 -0400" ], "Date": "Thu, 6 Jun 2019 11:26:34 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Bruce Richardson <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606152634.GG29521@hmswarspite.think-freely.org>", "References": "<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96888, "web_url": "http://patches.dpdk.org/comment/96888/", "msgid": "<BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-06T16:23:26", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Thursday, June 6, 2019 8:57 PM\n> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> Thomas Monjalon <thomas@monjalon.net>\n> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> On Thu, Jun 06, 2019 at 03:14:42PM +0000, Jerin Jacob Kollanukkaran wrote:\n> ><snip as this is getting long>\n> >\n> > I don't have any strong opinion on name prefix vs marking as\n> __rte_internal.\n> > Or combination of both. I am fine any approach.\n> >\n> > I have only strong option on not to induce objdump dependency for\n> checkpatch.\n> > For the reason mentioned in http://mails.dpdk.org/archives/dev/2019-\n> June/134160.html.\n> >\n> \n> Sorry, in my haste I didn't fully adress this in your previous email\n> \n> I'm really uncertain what you mean by introducing a checkpatch dependency\n> on objdump here. Theres nothing preventing you from running checkpatch\n> before you build the library. The only thing checkpatch does in dpdk is scan\n> the patches for sytle violations, and for changes in the map file for\n> movement to and from the EXPERIMENTAL section (i.e. no use of objdump).\n> \n> My patch modifies check-experimental-syms.sh (adding an objdump scan for\n> INTERNAL symbols, and renaming the script to check-special-syms.sh to be\n> more meaningful). That script however, is not run by checkpatch, its run\n> during compilation of the library to ensure that any symbol in a map file is\n> also tagged with __rte_internal in the corresponding object). Theres no path\n> from checkpatches to check-experimental-syms.sh\n> \n> What I meant in my last comment was that any dependency on objdump in\n> check-[experimental|special]-syms.sh already existed prior to this patch.\n\nI see. I thought your patches addressing issue related to \nhttp://patches.dpdk.org/patch/53590/\n\nWhere checkpatch.sh complaints when we add new internal driver API with\nout rte_experimental? That's where all the discussion started.\nThe reason why I was saying the API name prefix to mark as internal API is\nthat checkpatch can detect that case.\n\nExample:\nERROR: symbol otx2_mbox_alloc_msg_rsp is added in the DPDK_19.05 section, but is expected to be added in the EXPERIMENTAL section of the version map\n\n\n> \n> So I'm unsure why you think checkpatches has a dependency.\n> \n> Neil", "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 8AD1F1B970;\n\tThu, 6 Jun 2019 18:24:06 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com\n\t[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id AF32E1B96B\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 18:24:04 +0200 (CEST)", "from pps.filterd (m0045849.ppops.net [127.0.0.1])\n\tby mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx56GLFRm009926; Thu, 6 Jun 2019 09:24:03 -0700", "from sc-exch04.marvell.com ([199.233.58.184])\n\tby mx0a-0016f401.pphosted.com with ESMTP id 2sxwgnt94b-4\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tThu, 06 Jun 2019 09:24:03 -0700", "from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH04.marvell.com\n\t(10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tThu, 6 Jun 2019 09:23:31 -0700", "from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.51)\n\tby SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 09:23:31 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2518.namprd18.prod.outlook.com (20.179.93.10) with Microsoft\n\tSMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1943.22; Thu, 6 Jun 2019 16:23:26 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tThu, 6 Jun 2019 16:23:26 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=1GcOIiMN+GDaH955Yz+f0Y2nYDhgWbVNRlF4veYcS8A=;\n\tb=f2gaHZdlOXlVcXEwrjzZq05XtPCTplutvP+uLVl/6YlG5SfLO6C+2NHrzimNfVGvo8rB\n\tSE9lzKLwzd6tQW3kX8EVzB+wVlGfv5bpopEffgOWg4ZoaTI+N40GQNdUcQzNCtAKeoxL\n\tpxIg1m52oi3bnFpEh0kMUefBjlp9vg8DOZHX+wBpuY8+DyEqtLvJPBU8EvRSWcbYhdFZ\n\t3F0l3G9LMKdU52Jnb3F+CbIb+xVE5iQ3yxPa8X6QBiaUVbmV2yC2/88cpisI2wdszTN5\n\t0xRSnm7hGW7EGur3q6A/3EjQbHisDu7TRHo2WyBrUtd6CjXDumiiYAd2b+qxWDV0nMYt\n\tVA== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=1GcOIiMN+GDaH955Yz+f0Y2nYDhgWbVNRlF4veYcS8A=;\n\tb=J7LYZCGuATUMWuIe0Lw0jJLm2bCWH3Z5EB0w9o2312gDOkq8dMyQhCe83kPZhACBZ2jf+C3+pneemJrPk04ZvIxUhmn2nYYdVRBqh93wVdAnfl2zOw9iBvd40FO4juGuPISsyQxesELPzpoFw9oaW8t302h2wMVoACa1rt88HBE=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "CC": "Bruce Richardson <bruce.richardson@intel.com>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyAgAAgfgCAAAaRkIAAGyeAgAAFlPCAABM/AIAAAWqggAAE6wCAAAykAA==", "Date": "Thu, 6 Jun 2019 16:23:26 +0000", "Message-ID": "<BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606152634.GG29521@hmswarspite.think-freely.org>", "In-Reply-To": "<20190606152634.GG29521@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[122.178.234.223]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "f753e186-f016-41ee-2907-08d6ea9b4db3", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2518; ", "x-ms-traffictypediagnostic": "BYAPR18MB2518:", "x-ms-exchange-purlcount": "2", "x-microsoft-antispam-prvs": "<BYAPR18MB2518F57A07B619A550E944F3C8170@BYAPR18MB2518.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:9508;", "x-forefront-prvs": "00603B7EEF", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(346002)(39840400004)(376002)(136003)(366004)(396003)(189003)(199004)(13464003)(229853002)(55016002)(6306002)(14444005)(256004)(81166006)(64756008)(6436002)(73956011)(7736002)(76116006)(76176011)(6116002)(3846002)(71200400001)(486006)(66946007)(6916009)(14454004)(305945005)(316002)(966005)(52536014)(66476007)(86362001)(5660300002)(66556008)(8676002)(68736007)(7696005)(26005)(81156014)(186003)(9686003)(25786009)(476003)(53936002)(33656002)(71190400001)(66446008)(74316002)(66066001)(102836004)(2906002)(99286004)(6246003)(8936002)(4326008)(54906003)(446003)(478600001)(6506007)(53546011)(11346002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2518;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; MX:1; A:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "J1SS944yNMAw71HySvTJ64OY6CQ/Pez4b3UhkPVsX5arsgntbKWHFPvLa6S/Ed4Mf1PJUPAawhMjHTXzpVtQjikPqu597y8JhNp8z04H4kA85E93QriofD5HAPt6po7X6SoYn3wV1gI0Zp4ttNdCaaRgXPLjEKUvezk22zXsE6BFI6YrHDdgT2vR3bCYXgVtWlDs/bnGRcvzttqZucLEx/ti4dPWz6oCvTZkNcgLh0QBb3Qoq+jfq26wSDt/ZRAuEYUf/dss0Ofb3w1whllZQW9lZII5Jj1RkY6PzpX5Pz8YAlk/xiisYRDjAqHzZIlELlAqT2Wa97OWTa+18aVDTuxaLdJNsRYH6oMkKu6zht70S3wl8U8a0s1adh9dRNDufu4HPf4LFdlM+Kug4otbpqzl5e1g+Cl+w6QYF1ocz3Y=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "f753e186-f016-41ee-2907-08d6ea9b4db3", "X-MS-Exchange-CrossTenant-originalarrivaltime": "06 Jun 2019 16:23:26.2632\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2518", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-06_12:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96894, "web_url": "http://patches.dpdk.org/comment/96894/", "msgid": "<20190606165541.GH29521@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190606165541.GH29521@hmswarspite.think-freely.org", "date": "2019-06-06T16:55:41", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 06, 2019 at 04:23:26PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > -----Original Message-----\n> > From: Neil Horman <nhorman@tuxdriver.com>\n> > Sent: Thursday, June 6, 2019 8:57 PM\n> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > Thomas Monjalon <thomas@monjalon.net>\n> > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > \n> > On Thu, Jun 06, 2019 at 03:14:42PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > ><snip as this is getting long>\n> > >\n> > > I don't have any strong opinion on name prefix vs marking as\n> > __rte_internal.\n> > > Or combination of both. I am fine any approach.\n> > >\n> > > I have only strong option on not to induce objdump dependency for\n> > checkpatch.\n> > > For the reason mentioned in http://mails.dpdk.org/archives/dev/2019-\n> > June/134160.html.\n> > >\n> > \n> > Sorry, in my haste I didn't fully adress this in your previous email\n> > \n> > I'm really uncertain what you mean by introducing a checkpatch dependency\n> > on objdump here. Theres nothing preventing you from running checkpatch\n> > before you build the library. The only thing checkpatch does in dpdk is scan\n> > the patches for sytle violations, and for changes in the map file for\n> > movement to and from the EXPERIMENTAL section (i.e. no use of objdump).\n> > \n> > My patch modifies check-experimental-syms.sh (adding an objdump scan for\n> > INTERNAL symbols, and renaming the script to check-special-syms.sh to be\n> > more meaningful). That script however, is not run by checkpatch, its run\n> > during compilation of the library to ensure that any symbol in a map file is\n> > also tagged with __rte_internal in the corresponding object). Theres no path\n> > from checkpatches to check-experimental-syms.sh\n> > \n> > What I meant in my last comment was that any dependency on objdump in\n> > check-[experimental|special]-syms.sh already existed prior to this patch.\n> \n> I see. I thought your patches addressing issue related to \n> http://patches.dpdk.org/patch/53590/\n> \nIt does, it just does it in a different way than you do it.\n\n> Where checkpatch.sh complaints when we add new internal driver API with\n> out rte_experimental? That's where all the discussion started.\n> The reason why I was saying the API name prefix to mark as internal API is\n> that checkpatch can detect that case.\n> \nAh, thats a fair point, with my approach we need to add some code to\ncheck-symbol-change.sh such that any symbols listed in an INTERNAL section were\nignored. That would provide behavioral compatibility to what you were doing in\nyour patch.\n\nBut regardless, there is no dependency on objdump that wasn't there before, are\nwe in agreement on that?\n\nNeil\n\n> Example:\n> ERROR: symbol otx2_mbox_alloc_msg_rsp is added in the DPDK_19.05 section, but is expected to be added in the EXPERIMENTAL section of the version map\n> \n> \n> > \n> > So I'm unsure why you think checkpatches has a dependency.\n> > \n> > Neil\n> \n>", "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 ACF881B970;\n\tThu, 6 Jun 2019 18:56:25 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id B6E961B95D\n\tfor <dev@dpdk.org>; Thu, 6 Jun 2019 18:56:24 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hYvgX-00055u-Ho; Thu, 06 Jun 2019 12:56:20 -0400" ], "Date": "Thu, 6 Jun 2019 12:55:41 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Bruce Richardson <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190606165541.GH29521@hmswarspite.think-freely.org>", "References": "<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606152634.GG29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-1.2 (-)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96915, "web_url": "http://patches.dpdk.org/comment/96915/", "msgid": "<BYAPR18MB24248698383EF62BC4E983FCC8100@BYAPR18MB2424.namprd18.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR18MB24248698383EF62BC4E983FCC8100@BYAPR18MB2424.namprd18.prod.outlook.com", "date": "2019-06-07T09:41:07", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "content": "> -----Original Message-----\n> From: Neil Horman <nhorman@tuxdriver.com>\n> Sent: Thursday, June 6, 2019 10:26 PM\n> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> Thomas Monjalon <thomas@monjalon.net>\n> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> \n> On Thu, Jun 06, 2019 at 04:23:26PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > -----Original Message-----\n> > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > Sent: Thursday, June 6, 2019 8:57 PM\n> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > > Thomas Monjalon <thomas@monjalon.net>\n> > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > >\n> > > On Thu, Jun 06, 2019 at 03:14:42PM +0000, Jerin Jacob Kollanukkaran\n> wrote:\n> > > ><snip as this is getting long>\n> > > >\n> > > > I don't have any strong opinion on name prefix vs marking as\n> > > __rte_internal.\n> > > > Or combination of both. I am fine any approach.\n> > > >\n> > > > I have only strong option on not to induce objdump dependency for\n> > > checkpatch.\n> > > > For the reason mentioned in\n> > > > http://mails.dpdk.org/archives/dev/2019-\n> > > June/134160.html.\n> > > >\n> > >\n> > > Sorry, in my haste I didn't fully adress this in your previous email\n> > >\n> > > I'm really uncertain what you mean by introducing a checkpatch\n> > > dependency on objdump here. Theres nothing preventing you from\n> > > running checkpatch before you build the library. The only thing\n> > > checkpatch does in dpdk is scan the patches for sytle violations,\n> > > and for changes in the map file for movement to and from the\n> EXPERIMENTAL section (i.e. no use of objdump).\n> > >\n> > > My patch modifies check-experimental-syms.sh (adding an objdump scan\n> > > for INTERNAL symbols, and renaming the script to\n> > > check-special-syms.sh to be more meaningful). That script however,\n> > > is not run by checkpatch, its run during compilation of the library\n> > > to ensure that any symbol in a map file is also tagged with\n> > > __rte_internal in the corresponding object). Theres no path from\n> > > checkpatches to check-experimental-syms.sh\n> > >\n> > > What I meant in my last comment was that any dependency on objdump\n> > > in check-[experimental|special]-syms.sh already existed prior to this\n> patch.\n> >\n> > I see. I thought your patches addressing issue related to\n> > http://patches.dpdk.org/patch/53590/\n> >\n> It does, it just does it in a different way than you do it.\n> \n> > Where checkpatch.sh complaints when we add new internal driver API\n> > with out rte_experimental? That's where all the discussion started.\n> > The reason why I was saying the API name prefix to mark as internal\n> > API is that checkpatch can detect that case.\n> >\n> Ah, thats a fair point, with my approach we need to add some code to check-\n> symbol-change.sh such that any symbols listed in an INTERNAL section were\n> ignored. That would provide behavioral compatibility to what you were\n> doing in your patch.\n\nOK.\n\n> But regardless, there is no dependency on objdump that wasn't there\n> before, are we in agreement on that?\n\nYes.\n\n> \n> Neil\n> \n> > Example:\n> > ERROR: symbol otx2_mbox_alloc_msg_rsp is added in the DPDK_19.05\n> > section, but is expected to be added in the EXPERIMENTAL section of\n> > the version map\n> >\n> >\n> > >\n> > > So I'm unsure why you think checkpatches has a dependency.\n> > >\n> > > Neil\n> >\n> >", "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 2946D1B994;\n\tFri, 7 Jun 2019 11:41:14 +0200 (CEST)", "from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com\n\t[67.231.156.173]) by dpdk.org (Postfix) with ESMTP id DA8F31B953\n\tfor <dev@dpdk.org>; Fri, 7 Jun 2019 11:41:12 +0200 (CEST)", "from pps.filterd (m0045851.ppops.net [127.0.0.1])\n\tby mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id\n\tx579f4tr031837; Fri, 7 Jun 2019 02:41:12 -0700", "from sc-exch02.marvell.com ([199.233.58.182])\n\tby mx0b-0016f401.pphosted.com with ESMTP id 2sydhfsk0x-2\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); \n\tFri, 07 Jun 2019 02:41:12 -0700", "from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH02.marvell.com\n\t(10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3;\n\tFri, 7 Jun 2019 02:41:09 -0700", "from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.52)\n\tby SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server\n\t(TLS) id\n\t15.0.1367.3 via Frontend Transport; Fri, 7 Jun 2019 02:41:09 -0700", "from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by\n\tBYAPR18MB2680.namprd18.prod.outlook.com (20.179.94.91) with Microsoft\n\tSMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1965.14; Fri, 7 Jun 2019 09:41:07 +0000", "from BYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c]) by\n\tBYAPR18MB2424.namprd18.prod.outlook.com\n\t([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011;\n\tFri, 7 Jun 2019 09:41:07 +0000" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n\th=from : to : cc :\n\tsubject : date : message-id : references : in-reply-to : content-type\n\t: content-transfer-encoding : mime-version; s=pfpt0818;\n\tbh=KLHYwbIxjXUslJOHmW/il7nKus88TfnZs4/yWzsFkcM=;\n\tb=XlNNWdz3VOzBX6L6SD+cMfx1c1EgSi+R6ZaTkLvEZZxS4pm+6BWrQswXVJpeYnPVzpjn\n\t3RYaGrIMJHpd+D146o8TAKAH7VFHe0sTXYDIJnSsQKVN1DZ8ZhijiMFQ4g83rBpsCEWB\n\t20fIVwxM0NbwWftTDjsUmt0z4SaztQP0AAvAuKwNtoJCOk5qCSyQHU15oFoZ9irGyp/t\n\thl5jZrcK4VpyMhChbUZaplRz38SBCISAhEHPJWLH7VKceRMvPanMkM237I7/IhkwJ1G0\n\t6fbAjqs7JYSfWZf8V6uZPtyBEUbSys3/0ymhjWMZFMNj/ezYc+08eajc+nxXd0AB5pj+\n\tjw== ", "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=KLHYwbIxjXUslJOHmW/il7nKus88TfnZs4/yWzsFkcM=;\n\tb=U+8oyjoYB2QnJLan88RF/p721+RvBxPMqRjTqCe6OawG8OgxC/3wDuTPFknkDYql76tB/wXw6NXwLA2RCY6AJft46DeU5NpywAaxLzy1Tkkw1k8gkEFVehnAmBKDAk44+jMXhMcIVYLjt6FG2tOnwJ4r23z9GMCxIuYt4P2WQY4=" ], "From": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "To": "Neil Horman <nhorman@tuxdriver.com>", "CC": "Bruce Richardson <bruce.richardson@intel.com>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVEynnIvy0R3R0lkaWrQuIVgPnUKaNTWtQgAAIeYCAABfgAIABAvyAgAAgfgCAAAaRkIAAGyeAgAAFlPCAABM/AIAAAWqggAAE6wCAAAykAIAADEKAgAEYpBA=", "Date": "Fri, 7 Jun 2019 09:41:07 +0000", "Message-ID": "<BYAPR18MB24248698383EF62BC4E983FCC8100@BYAPR18MB2424.namprd18.prod.outlook.com>", "References": "<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606152634.GG29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606165541.GH29521@hmswarspite.think-freely.org>", "In-Reply-To": "<20190606165541.GH29521@hmswarspite.think-freely.org>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[14.140.231.66]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "724e7461-d134-40ce-8b7b-08d6eb2c445b", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);\n\tSRVR:BYAPR18MB2680; ", "x-ms-traffictypediagnostic": "BYAPR18MB2680:", "x-ms-exchange-purlcount": "2", "x-microsoft-antispam-prvs": "<BYAPR18MB26806D7E527BBF60F1D21DE6C8100@BYAPR18MB2680.namprd18.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;", "x-forefront-prvs": "0061C35778", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(346002)(366004)(376002)(39850400004)(136003)(396003)(13464003)(199004)(189003)(316002)(53936002)(54906003)(6246003)(966005)(74316002)(9686003)(6306002)(8936002)(68736007)(229853002)(55016002)(478600001)(6436002)(81156014)(14454004)(71190400001)(66066001)(33656002)(2906002)(81166006)(8676002)(71200400001)(4326008)(7736002)(305945005)(11346002)(66946007)(6506007)(53546011)(256004)(3846002)(66446008)(64756008)(66556008)(6116002)(76116006)(73956011)(5660300002)(52536014)(6916009)(86362001)(7696005)(99286004)(446003)(186003)(486006)(26005)(476003)(76176011)(55236004)(25786009)(102836004)(14444005)(66476007);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2680;\n\tH:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; A:1; MX:1; ", "received-spf": "None (protection.outlook.com: marvell.com does not designate\n\tpermitted sender hosts)", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam-message-info": "ywv1R02XX6tVTXil1OBkRxanW6rcBoUXz5h2p31tBKUm87yWgoK2E+dp8YkZp0e05WjtchBtV9D7NELbz31zk5vQI9Z+3NgdZVbdww/kYt7auphcjWgQA6NFXO+V4PkQNkaeMuBkUtPghLaMh1wtnlYgqYNZTDHShc/h4OS9cZq5fjzQQXkWz1xfM/7RqcHMa/GYovDpobr1050uffeTByqpc+lVALUvDtW1YyYhR3VRyAepJJ7njfy6dzhSgxQM2iUIjc1lecnJscj10Vk0BMSJQGtmtNsrgRnKZsIjCc+LmAxUOwpIzrARWjpOgkUVySe8yy+Z5P0LGhC0+yd4ISpC9qa8jxujDVvwwwSTOTmoJGaU/SplGiJMWZCVLM4AItqE9pJZZWI49fO3AlX40+RT/Ai8fC2R+tkVbSouN30=", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-Network-Message-Id": "724e7461-d134-40ce-8b7b-08d6eb2c445b", "X-MS-Exchange-CrossTenant-originalarrivaltime": "07 Jun 2019 09:41:07.5833\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "70e1fb47-1155-421d-87fc-2e58f638b6e0", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "jerinj@marvell.com", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR18MB2680", "X-OriginatorOrg": "marvell.com", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:, ,\n\tdefinitions=2019-06-07_04:, , signatures=0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96918, "web_url": "http://patches.dpdk.org/comment/96918/", "msgid": "<20190607103530.GA26017@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20190607103530.GA26017@hmswarspite.think-freely.org", "date": "2019-06-07T10:35:30", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 Fri, Jun 07, 2019 at 09:41:07AM +0000, Jerin Jacob Kollanukkaran wrote:\n> > -----Original Message-----\n> > From: Neil Horman <nhorman@tuxdriver.com>\n> > Sent: Thursday, June 6, 2019 10:26 PM\n> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > Thomas Monjalon <thomas@monjalon.net>\n> > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > \n> > On Thu, Jun 06, 2019 at 04:23:26PM +0000, Jerin Jacob Kollanukkaran wrote:\n> > > > -----Original Message-----\n> > > > From: Neil Horman <nhorman@tuxdriver.com>\n> > > > Sent: Thursday, June 6, 2019 8:57 PM\n> > > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> > > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> > > > Thomas Monjalon <thomas@monjalon.net>\n> > > > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> > > >\n> > > > On Thu, Jun 06, 2019 at 03:14:42PM +0000, Jerin Jacob Kollanukkaran\n> > wrote:\n> > > > ><snip as this is getting long>\n> > > > >\n> > > > > I don't have any strong opinion on name prefix vs marking as\n> > > > __rte_internal.\n> > > > > Or combination of both. I am fine any approach.\n> > > > >\n> > > > > I have only strong option on not to induce objdump dependency for\n> > > > checkpatch.\n> > > > > For the reason mentioned in\n> > > > > http://mails.dpdk.org/archives/dev/2019-\n> > > > June/134160.html.\n> > > > >\n> > > >\n> > > > Sorry, in my haste I didn't fully adress this in your previous email\n> > > >\n> > > > I'm really uncertain what you mean by introducing a checkpatch\n> > > > dependency on objdump here. Theres nothing preventing you from\n> > > > running checkpatch before you build the library. The only thing\n> > > > checkpatch does in dpdk is scan the patches for sytle violations,\n> > > > and for changes in the map file for movement to and from the\n> > EXPERIMENTAL section (i.e. no use of objdump).\n> > > >\n> > > > My patch modifies check-experimental-syms.sh (adding an objdump scan\n> > > > for INTERNAL symbols, and renaming the script to\n> > > > check-special-syms.sh to be more meaningful). That script however,\n> > > > is not run by checkpatch, its run during compilation of the library\n> > > > to ensure that any symbol in a map file is also tagged with\n> > > > __rte_internal in the corresponding object). Theres no path from\n> > > > checkpatches to check-experimental-syms.sh\n> > > >\n> > > > What I meant in my last comment was that any dependency on objdump\n> > > > in check-[experimental|special]-syms.sh already existed prior to this\n> > patch.\n> > >\n> > > I see. I thought your patches addressing issue related to\n> > > http://patches.dpdk.org/patch/53590/\n> > >\n> > It does, it just does it in a different way than you do it.\n> > \n> > > Where checkpatch.sh complaints when we add new internal driver API\n> > > with out rte_experimental? That's where all the discussion started.\n> > > The reason why I was saying the API name prefix to mark as internal\n> > > API is that checkpatch can detect that case.\n> > >\n> > Ah, thats a fair point, with my approach we need to add some code to check-\n> > symbol-change.sh such that any symbols listed in an INTERNAL section were\n> > ignored. That would provide behavioral compatibility to what you were\n> > doing in your patch.\n> \n> OK.\n> \n> > But regardless, there is no dependency on objdump that wasn't there\n> > before, are we in agreement on that?\n> \n> Yes.\n> \nok, let me revise this patch with that change in place. I'll also complete\ntagging of the affected internal functions so we have a better idea of what this\nchange entails\n\nNeil", "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 A30781BA56;\n\tFri, 7 Jun 2019 12:36:05 +0200 (CEST)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n\tby dpdk.org (Postfix) with ESMTP id BCBC71B9A5\n\tfor <dev@dpdk.org>; Fri, 7 Jun 2019 12:36:04 +0200 (CEST)", "from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com\n\t([2606:a000:111b:405a::162e] 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 1hZCE1-0003Wr-1J; Fri, 07 Jun 2019 06:35:59 -0400" ], "Date": "Fri, 7 Jun 2019 06:35:30 -0400", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "Jerin Jacob Kollanukkaran <jerinj@marvell.com>", "Cc": "Bruce Richardson <bruce.richardson@intel.com>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20190607103530.GA26017@hmswarspite.think-freely.org>", "References": "<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242411091EAED638C14711DEC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606152634.GG29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424114BBF9B945D131D16EBC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606165541.GH29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB24248698383EF62BC4E983FCC8100@BYAPR18MB2424.namprd18.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<BYAPR18MB24248698383EF62BC4E983FCC8100@BYAPR18MB2424.namprd18.prod.outlook.com>", "User-Agent": "Mutt/1.11.3 (2019-02-01)", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96938, "web_url": "http://patches.dpdk.org/comment/96938/", "msgid": "<3ab2fa96-e07b-b6c8-3a03-1b6ad2d5bb04@ashroe.eu>", "list_archive_url": "https://inbox.dpdk.org/dev/3ab2fa96-e07b-b6c8-3a03-1b6ad2d5bb04@ashroe.eu", "date": "2019-06-07T15:42:03", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 1310, "url": "http://patches.dpdk.org/api/people/1310/?format=api", "name": "Ray Kinsella", "email": "mdr@ashroe.eu" }, "content": "On 06/06/2019 16:03, Neil Horman wrote:\n> On Thu, Jun 06, 2019 at 02:02:03PM +0000, Jerin Jacob Kollanukkaran wrote:\n>>> -----Original Message-----\n>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>> Sent: Thursday, June 6, 2019 7:05 PM\n>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n>>> Thomas Monjalon <thomas@monjalon.net>\n>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>\n>>> On Thu, Jun 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran wrote:\n>>>>> -----Original Message-----\n>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>> Sent: Thursday, June 6, 2019 5:04 PM\n>>>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n>>>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n>>>>> Thomas Monjalon <thomas@monjalon.net>\n>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>\n>>>>> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran\n>>> wrote:\n>>>>>>> -----Original Message-----\n>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>>> Sent: Wednesday, June 5, 2019 11:41 PM\n>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>\n>>>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;\n>>>>>>> dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>\n>>>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>>>\n>>>>>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n>>>>>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n>>>>>>>> Kollanukkaran\n>>>>>>> wrote:\n>>>>>>>>>> -----Original Message-----\n>>>>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n>>>>>>>>>> To: dev@dpdk.org\n>>>>>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n>>>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n>>>>>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n>>>>>>>>>> <thomas@monjalon.net>\n>>>>>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal\n>>>>>>>>>> tag\n>>>>>>>>>>\n>>>>>>>>>> Hey-\n>>>>>>>>>> \tBased on our recent conversations regarding the use of\n>>>>>>>>>> symbols only meant for internal dpdk consumption (between\n>>>>>>>>>> dpdk libraries), this is an idea that I've come up with\n>>>>>>>>>> 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\n>>>>>>>>>> between DPDK libraries, but not by applications linking to\n>>>>>>>>>> them\n>>>>>>>>>> 2) We would like to document those symbols in the code, so\n>>>>>>>>>> as to note them clearly as for being meant for internal\n>>>>>>>>>> use only\n>>>>>>>>>> 3) Linker symbol visibility is a very coarse grained tool,\n>>>>>>>>>> and so there is no good way in a single library to mark\n>>>>>>>>>> items as being meant for use only by other DPDK libraries,\n>>>>>>>>>> at least not without some extensive runtime checking\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> Proposal:\n>>>>>>>>>> I'm proposing that we introduce the __rte_internal tag.\n>>>>>>>>>> From a coding standpoint it works a great deal like the\n>>>>>>>>>> __rte_experimental tag in that it expempts the tagged\n>>>>>>>>>> symbol from ABI constraints (as the only users should be\n>>>>>>>>>> represented in the DPDK build environment). Additionally,\n>>>>>>>>>> the __rte_internal macro resolves differently based on the\n>>>>>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n>>>>>>>>>> assumption that said flag should only ever be set if we\n>>>>>>>>>> are actually building DPDK libraries which will make use\n>>>>>>>>>> of internal calls). If the BUILDING_RTE_SDK flag is set\n>>>>>>>>>> __rte_internal resolves to __attribute__((section\n>>>>>>>>>> \"text.internal)), placing it in a special text section\n>>>>>>>>>> which is then used to validate that the the symbol appears\n>>>>>>>>>> in the INTERNAL section of the corresponding library version\n>>> map).\n>>>>>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal\n>>>>>>>>>> resolves to\n>>>>>>> __attribute__((error(\"...\"))), which causes any caller of the\n>>>>>>> tagged function to throw an error at compile time, indicating\n>>>>>>> that the symbol is not available for external use.\n>>>>>>>>>>\n>>>>>>>>>> This isn't a perfect solution, as applications can still\n>>>>>>>>>> hack around it of course,\n>>>>>>>>>\n>>>>>>>>> I think, one way to, avoid, hack around could be to,\n>>>>>>>>>\n>>>>>>>>> 1) at config stage, create a random number for the build\n>>>>>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n>>>>>>>>> function, compare the generated random number for allowing\n>>>>>>>>> the calls to make within the library. i.e leverage the fact\n>>>>>>>>> that external library would never know the random number\n>>>>>>>>> generated for the DPDK build\n>>>>>>> and internal driver code does.\n>>>>>>>>>\n>>>>>>>> Do we really need to care about this. If have some determined\n>>>>>>>> enough to hack around our limitations, then they surely know\n>>>>>>>> that they have an unsupported configuration. We just need to\n>>>>>>>> protect against inadvertent use of internals, IMHO.\n>>>>>>>>\n>>>>>>> I agree, I too had thought about doing some sort of internal\n>>>>>>> runtime checking to match internal only symbols, such that they\n>>>>>>> were only accessable by internally approved users, but it\n>>>>>>> started to feel like a great\n>>>>> deal of overhead.\n>>>>>>> Its a good idea for a general mechanism I think, but I believe\n>>>>>>> the value here is more to internally document which apis we want\n>>>>>>> to mark as being for internal use only, and create a lightweight\n>>>>>>> roadblock at build time to catch users inadvertently using them.\n>>>>>>> Determined users will get around anything, and theres not much\n>>>>>>> we can do to stop\n>>>>> them.\n>>>>>>\n>>>>>> I agree too. IMHO, Simply having following items would be enough\n>>>>>>\n>>>>>> 1) Avoid exposing the internal function prototype through public\n>>>>>> header files\n>>>>>> 2) Add @internal to API documentation\n>>>>>> 3) Just decide the name space for internal API for tooling(i.e not\n>>>>>> start with rte_ or so) Using objdump scheme to detect internal\n>>>>>> functions\n>>>>> requires the the library to build prior to run the checkpatch.\n>>>>>>\n>>>>>\n>>>>> No, I'm not comfortable with that approach, and I've stated why:\n>>>>> 1) Not exposing the functions via header files is a fine start\n>>>>>\n>>>>> 2) Adding internal documentation is also fine, but does nothing to\n>>>>> correlate the code implementing those functions to the\n>>>>> documentation. Its valuable to have a tag on a function identifying it as\n>>> internal only.\n>>>>>\n>>>>> 3) Using naming conventions to separate internal only from\n>>>>> non-internal functions is a vague approach, requiring future\n>>>>> developers to be cogniscent of the convention and make the\n>>>>> appropriate naming choices. It also implicitly restricts the\n>>>>> abliity for future developers to make naming changes in conflict\n>>>>> with that convention\n>>>>\n>>>> Enforcing the naming convention can be achieved through tooling as well.\n>>>>\n>>> Sure, but why enforce any function naming at all, when you don't have to.\n>>\n>> May I ask, why to enforce __rte_internal, when you don't have to\n>>\n> \n> Because its more clear. Implicitly deciding that any function not prefixed with\n> rte_ is internal only does nothing to prevent a developer from accidentally\n> naming a function incorrectly, exporting it, and allowing a user to call it. We\n> can move headers all you want, but we provide an ABI guarantee to end users, and\n> developers should have a way to clearly record that without having to check the\n> documentation for each function that an application developer wants to use.\n> \n> The long and the short of it for me is that I want a way for developers to opt\n> their code into an internal only condition, not to just document it as such\n> and hope its up to date. If they tag a function as __rte_internal then its\n> clearly marked as internal only, they have checks to ensure that its in the\n> INTERNAL section of the version map, and should that header somehow get\n> externally exported (see rte_mempool_check_cookies for an example of how thats\n> happened), users are prevented from using them at build time, rather than having\n> to ask questions on the list, or read documentation after an error to find out\n> \"oops, shouldn't have done that\".\n> \n> I think you'll find that going through all the header files, and bifurcating\n> them to public and private headers is a much larger undertaking than just\n> tagging those functions accordingly. a quick scan of all our header file for\n> the @internal tag shows about 260 instances of such functions, almost all of\n> which are published to applications. All of those functions would have to be\n> moved to private headers, and their requisite C files would need to be updated\n> to include the new header. with the use of __rte_internal, we just have tag the\n> functions as such, which can be handled with a cocinelle or awk script.\n> \n> Neil\n\nThis is good, I like alot about this, especially the build system\ncomplaining loudly when the developer does something they shouldn't - I\nthink anything that we can add that promotes good behaviors is to be\n100% welcomed.\n\nI also agree with the points made elsewhere that this is essentially\ntrying to solve a header problem, the mixing of public and private\nsymbols in what are public headers, with __rte_internal. Adding\n__rte_internal would essentially ratify that behavior, whereas I would\nargue that something inherently private, should never see the light of\nday in a public header.\n\nI completely get that it may be more work, however for me it is better\nway to fix this problem. It would also add completely clarity, all the\nextra hassle around does it have the rte_ prefix goes away - if it is in\na \"public header\" it is part of the ABI/API, end of discussion.\n\nFinally, not opposed to also asking folks putting symbols in the private\nheader to mark those symbols with __rte_internal.\n\n> \n> \n>>>\n>>>>>\n>>>>> 4) Adding a tag like __rte_internal creates an interlock whereby,\n>>>>> not only are internal functions excused from ABI constraints, but\n>>>>> forces developers to intentionally mark their internal functions as\n>>>>> being internal in the code, which is beneficial to clarlity of understanding\n>>> during the development process.\n>>>>\n>>>> No issues in adding __rte_internal. But, I am against current\n>>>> implementaion, Ie. adding objdump dependency\n>>> That dependency already exists for the __rte_external flag\n>>\n>> Sorry, I could not see the dependency.\n>>\n>> [master][dpdk.org] $ grep -ri \"objdump\" devtools/\n>> [master][dpdk.org] $ grep -ri \"objdump\" usertools/\n>> [master][dpdk.org] $ grep -ri \"__rte_external\" *\n>>\n>>>\n>>>> to checkpatch i.e developer has to build the library first so that\n>>>> checkpatch can can know, Is it belongs to internal section or not?\n>>>>\n>>> What developer is running checkpatch/posting patches without first building\n>>> their changes?\n>>\n>> # it is not developer, The CI/CD tools can quicky check the sanity of patches\n>> before the build itself. Why to add unnecessary dependency?\n>> # If some PMD is not building if the requirements are not meet(say AES NI PMD for crypto)\n>> then how do take care of the dependency.\n>>\n>>\n>>>\n>>>\n>>>>>\n>>>>> 5) Adding a tag like __rte_internal is explicit, and allows\n>>>>> developers to use a single header file instead of multiple header\n>>>>> files if they so choose\n>>>>>\n>>>>> We went through this with experimental symbols as well[1], and it\n>>>>> just makes more sense to me to clearly document in the code what\n>>>>> constitutes an internal symbol rather than relying on naming\n>>>>> conventions and hoping that developers read the documentation before\n>>>>> exporting a symbol publically.\n>>>>>\n>>>>>\n>>>>> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n>>>>>>>\n>>>>>>> If we really wanted to go down that road, we could use a\n>>>>>>> mechainsm simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL\n>>>>>>> infrastructure that the kernel uses, but that would required\n>>>>>>> building our own custom linker script, which seems like overkill here.\n>>>>>>>\n>>>>>>> Best\n>>>>>>> Neil\n>>>>>>>\n>>>>>>>> /Bruce\n>>>>>>>>\n>>>>>>\n>>>>\n>>\n>", "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 BB63A1BB32;\n\tFri, 7 Jun 2019 17:42:18 +0200 (CEST)", "from qrelay184.mxroute.com (qrelay184.mxroute.com [172.82.139.184])\n\tby dpdk.org (Postfix) with ESMTP id 728DA1BAA7\n\tfor <dev@dpdk.org>; Fri, 7 Jun 2019 17:42:17 +0200 (CEST)", "from filter002.mxroute.com (unknown [94.130.183.33])\n\tby qrelay184.mxroute.com (Postfix) with ESMTP id 90373160507;\n\tFri, 7 Jun 2019 11:42:16 -0400 (EDT)", "from galaxy.mxroute.com (unknown [23.92.70.113])\n\tby filter002.mxroute.com (Postfix) with ESMTPS id B43A53F0D4;\n\tFri, 7 Jun 2019 15:42:10 +0000 (UTC)", "from jfdmzpr04-ext.jf.intel.com ([134.134.139.73])\n\tby galaxy.mxroute.com with esmtpsa\n\t(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)\n\t(Exim 4.91) (envelope-from <mdr@ashroe.eu>)\n\tid 1hZH0L-0001CF-DP; Fri, 07 Jun 2019 11:42:10 -0400" ], "From": "Ray Kinsella <mdr@ashroe.eu>", "To": "dev@dpdk.org, Neil Horman <nhorman@tuxdriver.com>,\n\tJerin Jacob Kollanukkaran <jerinj@marvell.com>,\n\tbruce.richardson@intel.com, \n\tThomas Monjalon <thomas@monjalon.net>, Keith <keith.wiles@intel.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>", "Openpgp": "preference=signencrypt", "Autocrypt": "addr=mdr@ashroe.eu; keydata=\n\tmQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6\n\tASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s\n\tJtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j\n\tHV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr\n\tS51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS\n\tuxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++\n\tYICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux\n\tTpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH\n\tbKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5\n\t0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs\n\tbGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8\n\tB3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE\n\tmsa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn\n\tB3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f\n\tVRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a\n\t04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7\n\tJLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt\n\tTcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1\n\t+nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD\n\tdT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL\n\t92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC\n\tVqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5\n\txJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC\n\thf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5\n\tpt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S\n\tOhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v\n\tccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1\n\tpWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt\n\t07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj\n\ttkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y\n\tyfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u\n\tAjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ\n\tCWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf\n\tu+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17\n\tc+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA\n\tthNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK\n\t+d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8\n\tpcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2\n\tGpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75\n\tQO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l\n\tBGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ\n\twzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg==", "Message-ID": "<3ab2fa96-e07b-b6c8-3a03-1b6ad2d5bb04@ashroe.eu>", "Date": "Fri, 7 Jun 2019 16:42:03 +0100", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101\n\tThunderbird/60.7.0", "MIME-Version": "1.0", "In-Reply-To": "<20190606150354.GF29521@hmswarspite.think-freely.org>", "Content-Type": "text/plain; charset=utf-8", "Content-Language": "en-US", "Content-Transfer-Encoding": "7bit", "X-AuthUser": "mdr@ashroe.eu", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 96944, "web_url": "http://patches.dpdk.org/comment/96944/", "msgid": "<FAE90D0F-966D-4AC2-9FAA-EB6D8DE5EFC3@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/FAE90D0F-966D-4AC2-9FAA-EB6D8DE5EFC3@intel.com", "date": "2019-06-07T18:21:21", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "submitter": { "id": 166, "url": "http://patches.dpdk.org/api/people/166/?format=api", "name": "Wiles, Keith", "email": "keith.wiles@intel.com" }, "content": "> On Jun 7, 2019, at 10:42 AM, Ray Kinsella <mdr@ashroe.eu> wrote:\n> \n> \n> \n> On 06/06/2019 16:03, Neil Horman wrote:\n>> On Thu, Jun 06, 2019 at 02:02:03PM +0000, Jerin Jacob Kollanukkaran wrote:\n>>>> -----Original Message-----\n>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>> Sent: Thursday, June 6, 2019 7:05 PM\n>>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n>>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n>>>> Thomas Monjalon <thomas@monjalon.net>\n>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>> \n>>>> On Thu, Jun 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran wrote:\n>>>>>> -----Original Message-----\n>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>> Sent: Thursday, June 6, 2019 5:04 PM\n>>>>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n>>>>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n>>>>>> Thomas Monjalon <thomas@monjalon.net>\n>>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>> \n>>>>>> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran\n>>>> wrote:\n>>>>>>>> -----Original Message-----\n>>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>>>> Sent: Wednesday, June 5, 2019 11:41 PM\n>>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>\n>>>>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;\n>>>>>>>> dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>\n>>>>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n>>>>>>>> \n>>>>>>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n>>>>>>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n>>>>>>>>> Kollanukkaran\n>>>>>>>> wrote:\n>>>>>>>>>>> -----Original Message-----\n>>>>>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n>>>>>>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n>>>>>>>>>>> To: dev@dpdk.org\n>>>>>>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n>>>>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n>>>>>>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n>>>>>>>>>>> <thomas@monjalon.net>\n>>>>>>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal\n>>>>>>>>>>> tag\n>>>>>>>>>>> \n>>>>>>>>>>> Hey-\n>>>>>>>>>>> \tBased on our recent conversations regarding the use of\n>>>>>>>>>>> symbols only meant for internal dpdk consumption (between\n>>>>>>>>>>> dpdk libraries), this is an idea that I've come up with\n>>>>>>>>>>> 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\n>>>>>>>>>>> between DPDK libraries, but not by applications linking to\n>>>>>>>>>>> them\n>>>>>>>>>>> 2) We would like to document those symbols in the code, so\n>>>>>>>>>>> as to note them clearly as for being meant for internal\n>>>>>>>>>>> use only\n>>>>>>>>>>> 3) Linker symbol visibility is a very coarse grained tool,\n>>>>>>>>>>> and so there is no good way in a single library to mark\n>>>>>>>>>>> items as being meant for use only by other DPDK libraries,\n>>>>>>>>>>> at least not without some extensive runtime checking\n>>>>>>>>>>> \n>>>>>>>>>>> \n>>>>>>>>>>> Proposal:\n>>>>>>>>>>> I'm proposing that we introduce the __rte_internal tag.\n>>>>>>>>>>> From a coding standpoint it works a great deal like the\n>>>>>>>>>>> __rte_experimental tag in that it expempts the tagged\n>>>>>>>>>>> symbol from ABI constraints (as the only users should be\n>>>>>>>>>>> represented in the DPDK build environment). Additionally,\n>>>>>>>>>>> the __rte_internal macro resolves differently based on the\n>>>>>>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n>>>>>>>>>>> assumption that said flag should only ever be set if we\n>>>>>>>>>>> are actually building DPDK libraries which will make use\n>>>>>>>>>>> of internal calls). If the BUILDING_RTE_SDK flag is set\n>>>>>>>>>>> __rte_internal resolves to __attribute__((section\n>>>>>>>>>>> \"text.internal)), placing it in a special text section\n>>>>>>>>>>> which is then used to validate that the the symbol appears\n>>>>>>>>>>> in the INTERNAL section of the corresponding library version\n>>>> map).\n>>>>>>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal\n>>>>>>>>>>> resolves to\n>>>>>>>> __attribute__((error(\"...\"))), which causes any caller of the\n>>>>>>>> tagged function to throw an error at compile time, indicating\n>>>>>>>> that the symbol is not available for external use.\n>>>>>>>>>>> \n>>>>>>>>>>> This isn't a perfect solution, as applications can still\n>>>>>>>>>>> hack around it of course,\n>>>>>>>>>> \n>>>>>>>>>> I think, one way to, avoid, hack around could be to,\n>>>>>>>>>> \n>>>>>>>>>> 1) at config stage, create a random number for the build\n>>>>>>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n>>>>>>>>>> function, compare the generated random number for allowing\n>>>>>>>>>> the calls to make within the library. i.e leverage the fact\n>>>>>>>>>> that external library would never know the random number\n>>>>>>>>>> generated for the DPDK build\n>>>>>>>> and internal driver code does.\n>>>>>>>>>> \n>>>>>>>>> Do we really need to care about this. If have some determined\n>>>>>>>>> enough to hack around our limitations, then they surely know\n>>>>>>>>> that they have an unsupported configuration. We just need to\n>>>>>>>>> protect against inadvertent use of internals, IMHO.\n>>>>>>>>> \n>>>>>>>> I agree, I too had thought about doing some sort of internal\n>>>>>>>> runtime checking to match internal only symbols, such that they\n>>>>>>>> were only accessable by internally approved users, but it\n>>>>>>>> started to feel like a great\n>>>>>> deal of overhead.\n>>>>>>>> Its a good idea for a general mechanism I think, but I believe\n>>>>>>>> the value here is more to internally document which apis we want\n>>>>>>>> to mark as being for internal use only, and create a lightweight\n>>>>>>>> roadblock at build time to catch users inadvertently using them.\n>>>>>>>> Determined users will get around anything, and theres not much\n>>>>>>>> we can do to stop\n>>>>>> them.\n>>>>>>> \n>>>>>>> I agree too. IMHO, Simply having following items would be enough\n>>>>>>> \n>>>>>>> 1) Avoid exposing the internal function prototype through public\n>>>>>>> header files\n>>>>>>> 2) Add @internal to API documentation\n>>>>>>> 3) Just decide the name space for internal API for tooling(i.e not\n>>>>>>> start with rte_ or so) Using objdump scheme to detect internal\n>>>>>>> functions\n>>>>>> requires the the library to build prior to run the checkpatch.\n>>>>>>> \n>>>>>> \n>>>>>> No, I'm not comfortable with that approach, and I've stated why:\n>>>>>> 1) Not exposing the functions via header files is a fine start\n>>>>>> \n>>>>>> 2) Adding internal documentation is also fine, but does nothing to\n>>>>>> correlate the code implementing those functions to the\n>>>>>> documentation. Its valuable to have a tag on a function identifying it as\n>>>> internal only.\n>>>>>> \n>>>>>> 3) Using naming conventions to separate internal only from\n>>>>>> non-internal functions is a vague approach, requiring future\n>>>>>> developers to be cogniscent of the convention and make the\n>>>>>> appropriate naming choices. It also implicitly restricts the\n>>>>>> abliity for future developers to make naming changes in conflict\n>>>>>> with that convention\n>>>>> \n>>>>> Enforcing the naming convention can be achieved through tooling as well.\n>>>>> \n>>>> Sure, but why enforce any function naming at all, when you don't have to.\n>>> \n>>> May I ask, why to enforce __rte_internal, when you don't have to\n>>> \n>> \n>> Because its more clear. Implicitly deciding that any function not prefixed with\n>> rte_ is internal only does nothing to prevent a developer from accidentally\n>> naming a function incorrectly, exporting it, and allowing a user to call it. We\n>> can move headers all you want, but we provide an ABI guarantee to end users, and\n>> developers should have a way to clearly record that without having to check the\n>> documentation for each function that an application developer wants to use.\n>> \n>> The long and the short of it for me is that I want a way for developers to opt\n>> their code into an internal only condition, not to just document it as such\n>> and hope its up to date. If they tag a function as __rte_internal then its\n>> clearly marked as internal only, they have checks to ensure that its in the\n>> INTERNAL section of the version map, and should that header somehow get\n>> externally exported (see rte_mempool_check_cookies for an example of how thats\n>> happened), users are prevented from using them at build time, rather than having\n>> to ask questions on the list, or read documentation after an error to find out\n>> \"oops, shouldn't have done that\".\n>> \n>> I think you'll find that going through all the header files, and bifurcating\n>> them to public and private headers is a much larger undertaking than just\n>> tagging those functions accordingly. a quick scan of all our header file for\n>> the @internal tag shows about 260 instances of such functions, almost all of\n>> which are published to applications. All of those functions would have to be\n>> moved to private headers, and their requisite C files would need to be updated\n>> to include the new header. with the use of __rte_internal, we just have tag the\n>> functions as such, which can be handled with a cocinelle or awk script.\n>> \n>> Neil\n> \n> This is good, I like alot about this, especially the build system\n> complaining loudly when the developer does something they shouldn't - I\n> think anything that we can add that promotes good behaviors is to be\n> 100% welcomed.\n> \n> I also agree with the points made elsewhere that this is essentially\n> trying to solve a header problem, the mixing of public and private\n> symbols in what are public headers, with __rte_internal. Adding\n> __rte_internal would essentially ratify that behavior, whereas I would\n> argue that something inherently private, should never see the light of\n> day in a public header.\n> \n> I completely get that it may be more work, however for me it is better\n> way to fix this problem. It would also add completely clarity, all the\n> extra hassle around does it have the rte_ prefix goes away - if it is in\n> a \"public header\" it is part of the ABI/API, end of discussion.\n> \n> Finally, not opposed to also asking folks putting symbols in the private\n> header to mark those symbols with __rte_internal.\n\n+1 I think we need to do both split headers and __rte_internal for extra measure. I am still concerned we are adding more work for the developer, if not then at least we split the headers.\n> \n>> \n>> \n>>>> \n>>>>>> \n>>>>>> 4) Adding a tag like __rte_internal creates an interlock whereby,\n>>>>>> not only are internal functions excused from ABI constraints, but\n>>>>>> forces developers to intentionally mark their internal functions as\n>>>>>> being internal in the code, which is beneficial to clarlity of understanding\n>>>> during the development process.\n>>>>> \n>>>>> No issues in adding __rte_internal. But, I am against current\n>>>>> implementaion, Ie. adding objdump dependency\n>>>> That dependency already exists for the __rte_external flag\n>>> \n>>> Sorry, I could not see the dependency.\n>>> \n>>> [master][dpdk.org] $ grep -ri \"objdump\" devtools/\n>>> [master][dpdk.org] $ grep -ri \"objdump\" usertools/\n>>> [master][dpdk.org] $ grep -ri \"__rte_external\" *\n>>> \n>>>> \n>>>>> to checkpatch i.e developer has to build the library first so that\n>>>>> checkpatch can can know, Is it belongs to internal section or not?\n>>>>> \n>>>> What developer is running checkpatch/posting patches without first building\n>>>> their changes?\n>>> \n>>> # it is not developer, The CI/CD tools can quicky check the sanity of patches\n>>> before the build itself. Why to add unnecessary dependency?\n>>> # If some PMD is not building if the requirements are not meet(say AES NI PMD for crypto)\n>>> then how do take care of the dependency.\n>>> \n>>> \n>>>> \n>>>> \n>>>>>> \n>>>>>> 5) Adding a tag like __rte_internal is explicit, and allows\n>>>>>> developers to use a single header file instead of multiple header\n>>>>>> files if they so choose\n>>>>>> \n>>>>>> We went through this with experimental symbols as well[1], and it\n>>>>>> just makes more sense to me to clearly document in the code what\n>>>>>> constitutes an internal symbol rather than relying on naming\n>>>>>> conventions and hoping that developers read the documentation before\n>>>>>> exporting a symbol publically.\n>>>>>> \n>>>>>> \n>>>>>> [1] https://mails.dpdk.org/archives/dev/2017-December/083828.html\n>>>>>>>> \n>>>>>>>> If we really wanted to go down that road, we could use a\n>>>>>>>> mechainsm simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL\n>>>>>>>> infrastructure that the kernel uses, but that would required\n>>>>>>>> building our own custom linker script, which seems like overkill here.\n>>>>>>>> \n>>>>>>>> Best\n>>>>>>>> Neil\n>>>>>>>> \n>>>>>>>>> /Bruce\n\nRegards,\nKeith", "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 13B8A1BB92;\n\tFri, 7 Jun 2019 20:21:29 +0200 (CEST)", "from mga05.intel.com (mga05.intel.com [192.55.52.43])\n\tby dpdk.org (Postfix) with ESMTP id 931CF1BB91\n\tfor <dev@dpdk.org>; Fri, 7 Jun 2019 20:21:26 +0200 (CEST)", "from orsmga006.jf.intel.com ([10.7.209.51])\n\tby fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t07 Jun 2019 11:21:25 -0700", "from fmsmsx105.amr.corp.intel.com ([10.18.124.203])\n\tby orsmga006.jf.intel.com with ESMTP; 07 Jun 2019 11:21:24 -0700", "from fmsmsx122.amr.corp.intel.com (10.18.125.37) by\n\tFMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP\n\tServer (TLS) id 14.3.408.0; Fri, 7 Jun 2019 11:21:23 -0700", "from fmsmsx117.amr.corp.intel.com ([169.254.3.248]) by\n\tfmsmsx122.amr.corp.intel.com ([169.254.5.41]) with mapi id\n\t14.03.0415.000; Fri, 7 Jun 2019 11:21:23 -0700" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "From": "\"Wiles, Keith\" <keith.wiles@intel.com>", "To": "Ray Kinsella <mdr@ashroe.eu>", "CC": "dpdk-dev <dev@dpdk.org>, Neil Horman <nhorman@tuxdriver.com>, \"Jerin\n\tJacob Kollanukkaran\" <jerinj@marvell.com>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, Thomas Monjalon <thomas@monjalon.net>", "Thread-Topic": "[dpdk-dev] [EXT] [RFC PATCH 0/2] introduce __rte_internal tag", "Thread-Index": "AQHVHHB97aIDBKYr+Ump4lVIDa17J6aPLpUAgAGc/YCAACyCgA==", "Date": "Fri, 7 Jun 2019 18:21:21 +0000", "Message-ID": "<FAE90D0F-966D-4AC2-9FAA-EB6D8DE5EFC3@intel.com>", "References": "<20190525184346.27932-1-nhorman@tuxdriver.com>\n\t<BYAPR18MB24240660A3CDEB3E0B0347AAC8160@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n\t<20190605181108.GC554@hmswarspite.think-freely.org>\n\t<BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606113422.GA29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606133503.GB29521@hmswarspite.think-freely.org>\n\t<BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n\t<20190606150354.GF29521@hmswarspite.think-freely.org>\n\t<3ab2fa96-e07b-b6c8-3a03-1b6ad2d5bb04@ashroe.eu>", "In-Reply-To": "<3ab2fa96-e07b-b6c8-3a03-1b6ad2d5bb04@ashroe.eu>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[10.255.75.4]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-ID": "<68DA62054433A943A898D659F163D3BF@intel.com>", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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": 106338, "web_url": "http://patches.dpdk.org/comment/106338/", "msgid": "<20200109154922.GB11396@hmswarspite.think-freely.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20200109154922.GB11396@hmswarspite.think-freely.org", "date": "2020-01-09T15:49:22", "subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 Fri, Jun 07, 2019 at 06:21:21PM +0000, Wiles, Keith wrote:\n> \n> \n> > On Jun 7, 2019, at 10:42 AM, Ray Kinsella <mdr@ashroe.eu> wrote:\n> > \n> > \n> > \n> > On 06/06/2019 16:03, Neil Horman wrote:\n> >> On Thu, Jun 06, 2019 at 02:02:03PM +0000, Jerin Jacob Kollanukkaran wrote:\n> >>>> -----Original Message-----\n> >>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>> Sent: Thursday, June 6, 2019 7:05 PM\n> >>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> >>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> >>>> Thomas Monjalon <thomas@monjalon.net>\n> >>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>> \n> >>>> On Thu, Jun 06, 2019 at 12:04:57PM +0000, Jerin Jacob Kollanukkaran wrote:\n> >>>>>> -----Original Message-----\n> >>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>>>> Sent: Thursday, June 6, 2019 5:04 PM\n> >>>>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>\n> >>>>>> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;\n> >>>>>> Thomas Monjalon <thomas@monjalon.net>\n> >>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>>>> \n> >>>>>> On Thu, Jun 06, 2019 at 09:44:52AM +0000, Jerin Jacob Kollanukkaran\n> >>>> wrote:\n> >>>>>>>> -----Original Message-----\n> >>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>>>>>> Sent: Wednesday, June 5, 2019 11:41 PM\n> >>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>\n> >>>>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;\n> >>>>>>>> dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>\n> >>>>>>>> Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag\n> >>>>>>>> \n> >>>>>>>> On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote:\n> >>>>>>>>> On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob\n> >>>>>>>>> Kollanukkaran\n> >>>>>>>> wrote:\n> >>>>>>>>>>> -----Original Message-----\n> >>>>>>>>>>> From: Neil Horman <nhorman@tuxdriver.com>\n> >>>>>>>>>>> Sent: Sunday, May 26, 2019 12:14 AM\n> >>>>>>>>>>> To: dev@dpdk.org\n> >>>>>>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>; Jerin Jacob\n> >>>>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Bruce Richardson\n> >>>>>>>>>>> <bruce.richardson@intel.com>; Thomas Monjalon\n> >>>>>>>>>>> <thomas@monjalon.net>\n> >>>>>>>>>>> Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal\n> >>>>>>>>>>> tag\n> >>>>>>>>>>> \n> >>>>>>>>>>> Hey-\n> >>>>>>>>>>> \tBased on our recent conversations regarding the use of\n> >>>>>>>>>>> symbols only meant for internal dpdk consumption (between\n> >>>>>>>>>>> dpdk libraries), this is an idea that I've come up with\n> >>>>>>>>>>> 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\n> >>>>>>>>>>> between DPDK libraries, but not by applications linking to\n> >>>>>>>>>>> them\n> >>>>>>>>>>> 2) We would like to document those symbols in the code, so\n> >>>>>>>>>>> as to note them clearly as for being meant for internal\n> >>>>>>>>>>> use only\n> >>>>>>>>>>> 3) Linker symbol visibility is a very coarse grained tool,\n> >>>>>>>>>>> and so there is no good way in a single library to mark\n> >>>>>>>>>>> items as being meant for use only by other DPDK libraries,\n> >>>>>>>>>>> at least not without some extensive runtime checking\n> >>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>>> Proposal:\n> >>>>>>>>>>> I'm proposing that we introduce the __rte_internal tag.\n> >>>>>>>>>>> From a coding standpoint it works a great deal like the\n> >>>>>>>>>>> __rte_experimental tag in that it expempts the tagged\n> >>>>>>>>>>> symbol from ABI constraints (as the only users should be\n> >>>>>>>>>>> represented in the DPDK build environment). Additionally,\n> >>>>>>>>>>> the __rte_internal macro resolves differently based on the\n> >>>>>>>>>>> definition of the BUILDING_RTE_SDK flag (working under the\n> >>>>>>>>>>> assumption that said flag should only ever be set if we\n> >>>>>>>>>>> are actually building DPDK libraries which will make use\n> >>>>>>>>>>> of internal calls). If the BUILDING_RTE_SDK flag is set\n> >>>>>>>>>>> __rte_internal resolves to __attribute__((section\n> >>>>>>>>>>> \"text.internal)), placing it in a special text section\n> >>>>>>>>>>> which is then used to validate that the the symbol appears\n> >>>>>>>>>>> in the INTERNAL section of the corresponding library version\n> >>>> map).\n> >>>>>>>>>>> If BUILDING_RTE_SDK is not set, then __rte_internal\n> >>>>>>>>>>> resolves to\n> >>>>>>>> __attribute__((error(\"...\"))), which causes any caller of the\n> >>>>>>>> tagged function to throw an error at compile time, indicating\n> >>>>>>>> that the symbol is not available for external use.\n> >>>>>>>>>>> \n> >>>>>>>>>>> This isn't a perfect solution, as applications can still\n> >>>>>>>>>>> hack around it of course,\n> >>>>>>>>>> \n> >>>>>>>>>> I think, one way to, avoid, hack around could be to,\n> >>>>>>>>>> \n> >>>>>>>>>> 1) at config stage, create a random number for the build\n> >>>>>>>>>> 2) introduce RTE_CALL_INTERNAL macro for calling internal\n> >>>>>>>>>> function, compare the generated random number for allowing\n> >>>>>>>>>> the calls to make within the library. i.e leverage the fact\n> >>>>>>>>>> that external library would never know the random number\n> >>>>>>>>>> generated for the DPDK build\n> >>>>>>>> and internal driver code does.\n> >>>>>>>>>> \n> >>>>>>>>> Do we really need to care about this. If have some determined\n> >>>>>>>>> enough to hack around our limitations, then they surely know\n> >>>>>>>>> that they have an unsupported configuration. We just need to\n> >>>>>>>>> protect against inadvertent use of internals, IMHO.\n> >>>>>>>>> \n> >>>>>>>> I agree, I too had thought about doing some sort of internal\n> >>>>>>>> runtime checking to match internal only symbols, such that they\n> >>>>>>>> were only accessable by internally approved users, but it\n> >>>>>>>> started to feel like a great\n> >>>>>> deal of overhead.\n> >>>>>>>> Its a good idea for a general mechanism I think, but I believe\n> >>>>>>>> the value here is more to internally document which apis we want\n> >>>>>>>> to mark as being for internal use only, and create a lightweight\n> >>>>>>>> roadblock at build time to catch users inadvertently using them.\n> >>>>>>>> Determined users will get around anything, and theres not much\n> >>>>>>>> we can do to stop\n> >>>>>> them.\n> >>>>>>> \n> >>>>>>> I agree too. IMHO, Simply having following items would be enough\n> >>>>>>> \n> >>>>>>> 1) Avoid exposing the internal function prototype through public\n> >>>>>>> header files\n> >>>>>>> 2) Add @internal to API documentation\n> >>>>>>> 3) Just decide the name space for internal API for tooling(i.e not\n> >>>>>>> start with rte_ or so) Using objdump scheme to detect internal\n> >>>>>>> functions\n> >>>>>> requires the the library to build prior to run the checkpatch.\n> >>>>>>> \n> >>>>>> \n> >>>>>> No, I'm not comfortable with that approach, and I've stated why:\n> >>>>>> 1) Not exposing the functions via header files is a fine start\n> >>>>>> \n> >>>>>> 2) Adding internal documentation is also fine, but does nothing to\n> >>>>>> correlate the code implementing those functions to the\n> >>>>>> documentation. Its valuable to have a tag on a function identifying it as\n> >>>> internal only.\n> >>>>>> \n> >>>>>> 3) Using naming conventions to separate internal only from\n> >>>>>> non-internal functions is a vague approach, requiring future\n> >>>>>> developers to be cogniscent of the convention and make the\n> >>>>>> appropriate naming choices. It also implicitly restricts the\n> >>>>>> abliity for future developers to make naming changes in conflict\n> >>>>>> with that convention\n> >>>>> \n> >>>>> Enforcing the naming convention can be achieved through tooling as well.\n> >>>>> \n> >>>> Sure, but why enforce any function naming at all, when you don't have to.\n> >>> \n> >>> May I ask, why to enforce __rte_internal, when you don't have to\n> >>> \n> >> \n> >> Because its more clear. Implicitly deciding that any function not prefixed with\n> >> rte_ is internal only does nothing to prevent a developer from accidentally\n> >> naming a function incorrectly, exporting it, and allowing a user to call it. We\n> >> can move headers all you want, but we provide an ABI guarantee to end users, and\n> >> developers should have a way to clearly record that without having to check the\n> >> documentation for each function that an application developer wants to use.\n> >> \n> >> The long and the short of it for me is that I want a way for developers to opt\n> >> their code into an internal only condition, not to just document it as such\n> >> and hope its up to date. If they tag a function as __rte_internal then its\n> >> clearly marked as internal only, they have checks to ensure that its in the\n> >> INTERNAL section of the version map, and should that header somehow get\n> >> externally exported (see rte_mempool_check_cookies for an example of how thats\n> >> happened), users are prevented from using them at build time, rather than having\n> >> to ask questions on the list, or read documentation after an error to find out\n> >> \"oops, shouldn't have done that\".\n> >> \n> >> I think you'll find that going through all the header files, and bifurcating\n> >> them to public and private headers is a much larger undertaking than just\n> >> tagging those functions accordingly. a quick scan of all our header file for\n> >> the @internal tag shows about 260 instances of such functions, almost all of\n> >> which are published to applications. All of those functions would have to be\n> >> moved to private headers, and their requisite C files would need to be updated\n> >> to include the new header. with the use of __rte_internal, we just have tag the\n> >> functions as such, which can be handled with a cocinelle or awk script.\n> >> \n> >> Neil\n> > \n> > This is good, I like alot about this, especially the build system\n> > complaining loudly when the developer does something they shouldn't - I\n> > think anything that we can add that promotes good behaviors is to be\n> > 100% welcomed.\n> > \n> > I also agree with the points made elsewhere that this is essentially\n> > trying to solve a header problem, the mixing of public and private\n> > symbols in what are public headers, with __rte_internal. Adding\n> > __rte_internal would essentially ratify that behavior, whereas I would\n> > argue that something inherently private, should never see the light of\n> > day in a public header.\n> > \n> > I completely get that it may be more work, however for me it is better\n> > way to fix this problem. It would also add completely clarity, all the\n> > extra hassle around does it have the rte_ prefix goes away - if it is in\n> > a \"public header\" it is part of the ABI/API, end of discussion.\n> > \n> > Finally, not opposed to also asking folks putting symbols in the private\n> > header to mark those symbols with __rte_internal.\n> \n> +1 I think we need to do both split headers and __rte_internal for extra measure. I am still concerned we are adding more work for the developer, if not then at least we split the headers.\nI think this makes sense. Perhaps we could add a check in checkpatch to warn a\nuser if the __rte_internal tag is present in a header that has been copied to\nthe builds include directory (i.e. was specified as SYMLINK-$(VAR) in the\nmakefile). Would that help?\n\nNeil", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 6490DA046B;\n\tThu, 9 Jan 2020 16:49:41 +0100 (CET)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 278031DBA7;\n\tThu, 9 Jan 2020 16:49:41 +0100 (CET)", "from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])\n by dpdk.org (Postfix) with ESMTP id E4D4C1DB96\n for <dev@dpdk.org>; Thu, 9 Jan 2020 16:49:39 +0100 (CET)", "from 2606-a000-111b-43ee-0000-0000-0000-115f.inf6.spectrum.com\n ([2606:a000:111b:43ee::115f] helo=localhost)\n by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63)\n (envelope-from <nhorman@tuxdriver.com>)\n id 1ipa3m-0003Qu-U8; Thu, 09 Jan 2020 10:49:31 -0500" ], "Date": "Thu, 9 Jan 2020 10:49:22 -0500", "From": "Neil Horman <nhorman@tuxdriver.com>", "To": "\"Wiles, Keith\" <keith.wiles@intel.com>", "Cc": "Ray Kinsella <mdr@ashroe.eu>, dpdk-dev <dev@dpdk.org>,\n Jerin Jacob Kollanukkaran <jerinj@marvell.com>,\n \"Richardson, Bruce\" <bruce.richardson@intel.com>,\n Thomas Monjalon <thomas@monjalon.net>", "Message-ID": "<20200109154922.GB11396@hmswarspite.think-freely.org>", "References": "<20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com>\n <20190605181108.GC554@hmswarspite.think-freely.org>\n <BYAPR18MB24240EF19CFA1ADFE6B52AD1C8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n <20190606113422.GA29521@hmswarspite.think-freely.org>\n <BYAPR18MB242407B0A2A21E187843917FC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n <20190606133503.GB29521@hmswarspite.think-freely.org>\n <BYAPR18MB2424C6DED1CC2A05377D342EC8170@BYAPR18MB2424.namprd18.prod.outlook.com>\n <20190606150354.GF29521@hmswarspite.think-freely.org>\n <3ab2fa96-e07b-b6c8-3a03-1b6ad2d5bb04@ashroe.eu>\n <FAE90D0F-966D-4AC2-9FAA-EB6D8DE5EFC3@intel.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<FAE90D0F-966D-4AC2-9FAA-EB6D8DE5EFC3@intel.com>", "X-Spam-Score": "-2.9 (--)", "X-Spam-Status": "No", "Subject": "Re: [dpdk-dev] [EXT] [RFC PATCH 0/2] 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 <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 <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]