From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 244AAA0096 for ; Thu, 6 Jun 2019 11:45:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BD8C31B95A; Thu, 6 Jun 2019 11:45:00 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 833741B959 for ; Thu, 6 Jun 2019 11:44:59 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x569ivAb010202; Thu, 6 Jun 2019 02:44:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=tsYCd9OtEOLxh9a7Dzfz1UdsjZOsUA8vWPxRVROkGsE=; b=yLFYis5j4IrG3KhT196Va+u2g39ulHvbP4inLBdaUi53U6zyzlBAysk34BMOa5MAznPx onc+JISEcbq52bl4SbIETBtctwmshUjIKShBtDycA0xdS6o4aO5V5T0GMmPgtFntNMMg fN4zBE8zJjqylHMMjZh4KBpq41q8EwfF2SnyzA0E2U/c+0qvT8qA6WycsIrGet6oxjFx MvgLe/Gm8SLOSRUbZHMNM1Br0cJ6SucndBWCjPzWYHIckEYyswIIoIZuVVbp8dffuySD SKTfm4eBFmTaCA3RdhTBF2en/cmlJVeYdbCq3bQK0gANNFvSyvsyDmxzRRVDYcZ/pymU 0Q== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2sxwgnrpgd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Jun 2019 02:44:58 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 6 Jun 2019 02:44:57 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.52) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 6 Jun 2019 02:44:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tsYCd9OtEOLxh9a7Dzfz1UdsjZOsUA8vWPxRVROkGsE=; b=Hrh3ZBsQN761wJ8gPRxxhPralswVp6j6cq5WtsKOU634iJMni3cKTMdvsBsfa4no/b3KeS82HMzaU3tbbZHAuo/SbgRBJ/i11bAQAx7GawpwwlTacMXZyIrOjPtjGFQMUnuQXqR06odfHYyPF1MsMwuL8c14mJIwxTt/fZBG89k= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2949.namprd18.prod.outlook.com (20.179.59.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Thu, 6 Jun 2019 09:44:52 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::1ce4:557d:eeb8:843c]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::1ce4:557d:eeb8:843c%7]) with mapi id 15.20.1965.011; Thu, 6 Jun 2019 09:44:52 +0000 From: Jerin Jacob Kollanukkaran To: Neil Horman , Bruce Richardson CC: "dev@dpdk.org" , Thomas Monjalon 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: References: <20190525184346.27932-1-nhorman@tuxdriver.com> <20190605164541.GH1550@bricha3-MOBL.ger.corp.intel.com> <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; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2949; x-ms-traffictypediagnostic: BYAPR18MB2949: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(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); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2949; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted 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 (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:, , definitions=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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Neil Horman > Sent: Wednesday, June 5, 2019 11:41 PM > To: Bruce Richardson > Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org; Thomas > Monjalon > Subject: Re: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag >=20 > On Wed, Jun 05, 2019 at 05:45:41PM +0100, Bruce Richardson wrote: > > On Wed, Jun 05, 2019 at 04:24:09PM +0000, Jerin Jacob Kollanukkaran > wrote: > > > > -----Original Message----- > > > > From: Neil Horman > > > > Sent: Sunday, May 26, 2019 12:14 AM > > > > To: dev@dpdk.org > > > > Cc: Neil Horman ; Jerin Jacob Kollanukkaran > > > > ; Bruce Richardson > > > > ; Thomas Monjalon > > > > > > > > Subject: [EXT] [RFC PATCH 0/2] introduce __rte_internal tag > > > > > > > > Hey- > > > > Based on our recent conversations regarding the use of symbols > > > > only meant for internal dpdk consumption (between dpdk libraries), > > > > this is an idea that I've come up with that I'd like to get some > > > > feedback on > > > > > > > > Summary: > > > > 1) We have symbols in the DPDK that are meant to be used between > > > > DPDK libraries, but not by applications linking to them > > > > 2) We would like to document those symbols in the code, so as to > > > > note them clearly as for being meant for internal use only > > > > 3) Linker symbol visibility is a very coarse grained tool, and so > > > > there is no good way in a single library to mark items as being > > > > meant for use only by other DPDK libraries, at least not without > > > > some extensive runtime checking > > > > > > > > > > > > Proposal: > > > > I'm proposing that we introduce the __rte_internal tag. From a > > > > coding standpoint it works a great deal like the > > > > __rte_experimental tag in that it expempts the tagged symbol from > > > > ABI constraints (as the only users should be represented in the > > > > DPDK build environment). Additionally, the __rte_internal macro > > > > resolves differently based on the definition of the > > > > BUILDING_RTE_SDK flag (working under the assumption that said flag > > > > should only ever be set if we are actually building DPDK libraries > > > > which will make use of internal calls). If the BUILDING_RTE_SDK > > > > flag is set __rte_internal resolves to __attribute__((section > > > > "text.internal)), placing it in a special text section which is > > > > then used to validate that the the symbol appears in the INTERNAL > > > > section of the corresponding library version map). If > > > > BUILDING_RTE_SDK is not set, then __rte_internal resolves to > __attribute__((error("..."))), which causes any caller of the tagged func= tion > to throw an error at compile time, indicating that the symbol is not avai= lable > for external use. > > > > > > > > This isn't a perfect solution, as applications can still hack > > > > around it of course, > > > > > > I think, one way to, avoid, hack around could be to, > > > > > > 1) at config stage, create a random number for the build > > > 2) introduce RTE_CALL_INTERNAL macro for calling internal function, > > > compare the generated random number for allowing the calls to make > > > within the library. i.e leverage the fact that external library > > > would never know the random number generated for the DPDK build > and internal driver code does. > > > > > Do we really need to care about this. If have some determined enough > > to hack around our limitations, then they surely know that they have > > an unsupported configuration. We just need to protect against > > inadvertent use of internals, IMHO. > > > I agree, I too had thought about doing some sort of internal runtime chec= king > to match internal only symbols, such that they were only accessable by > internally approved users, but it started to feel like a great deal of ov= erhead. > Its a good idea for a general mechanism I think, but I believe the value = here is > more to internally document which apis we want to mark as being for > internal use only, and create a lightweight roadblock at build time to ca= tch > users inadvertently using them. Determined users will get around anythin= g, > and theres not much we can do to stop them. I agree too. IMHO, Simply having following items would be enough 1) Avoid exposing the internal function prototype through public header fil= es 2) Add @internal to API documentation 3) Just decide the name space for internal API for tooling(i.e not start wi= th rte_ or so) Using objdump scheme to detect internal functions requires the the library = to build prior to run the checkpatch. >=20 > If we really wanted to go down that road, we could use a mechainsm > simmilar to the EXPORT_SYMBOL / EXPORT_SYMBOL_GPL infrastructure that > the kernel uses, but that would required building our own custom linker > script, which seems like overkill here. >=20 > Best > Neil >=20 > > /Bruce > >