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 0460DA0096 for ; Wed, 5 Jun 2019 18:24:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 891551BBB4; Wed, 5 Jun 2019 18:24:14 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 57EE31BA96 for ; Wed, 5 Jun 2019 18:24:13 +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 x55GJbpj001152; Wed, 5 Jun 2019 09:24:12 -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=ShvMDdnt6o2y2GYkpEbNjuzjDY07Yy3Tf7RAyxemdDU=; b=UNpFSQnkevoQ/pMJZ+zjI83iTx9dXllFFpvmQPvUUYbOKwV7TrODNE0OgGVKnxw+BJPx MnZqqdDKjGLVCqQKYOkma3SF1fqXcvxM8lWgNuXSZEV6hBD9LLD0JAV/6IdZtZLz7Phd 6msfIq7zd+fArLYtKi8Fo+rkrhzB5DEg014ctY6bSRSjLe/w9OYWWL1IMSR/apGYzR6m ZTstAekcucsddbe5ympcCf1Cd/zbqNeuC0FWXEbbI7i1jSZfTO8SqeT3W8y/5/1rY1tq mHZhLU4fkJjNVR3BSdM5mR8dTN7fEG/MtndcfagKUDTmHJ54IOj61wk/gkP9ETpPhYbY FA== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2sxfw4ge3k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Jun 2019 09:24:12 -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; Wed, 5 Jun 2019 09:24:11 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.56) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 5 Jun 2019 09:24:11 -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=ShvMDdnt6o2y2GYkpEbNjuzjDY07Yy3Tf7RAyxemdDU=; b=b8zdzjk5tLGMl+EDKNFl9GPtOzoru18HDj17L+/ySoAq2UADA398nauwHV3hs7zx4WvCgILBWaZPpQwhRMwy3u5nXQHfah30seCCJIK1ZFxXFGEK82nD2gasGJspGj6ppA1TWteQ7Njh5RKbb/52XOlo2sgnXeaWVWjorOC9dZM= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2645.namprd18.prod.outlook.com (20.179.92.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Wed, 5 Jun 2019 16:24:09 +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; Wed, 5 Jun 2019 16:24:09 +0000 From: Jerin Jacob Kollanukkaran To: Neil Horman , "dev@dpdk.org" CC: Bruce Richardson , Thomas Monjalon 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: 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; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2645; x-ms-traffictypediagnostic: BYAPR18MB2645: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(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); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2645; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 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 (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:, , definitions=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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----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 >=20 > 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 >=20 > 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 the= m > clearly as for being meant for internal use only > 3) Linker symbol visibility is a very coarse grained tool, and so there i= s no good > way in a single library to mark items as being meant for use only by othe= r > DPDK libraries, at least not without some extensive runtime checking >=20 >=20 > 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 ma= ke use > of internal calls). If the BUILDING_RTE_SDK flag is set __rte_internal r= esolves > 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 INTERNA= L > section of the corresponding library version map). If BUILDING_RTE_SDK i= s > not set, then __rte_internal resolves to __attribute__((error("..."))), w= hich > causes any caller of the tagged function to throw an error at compile tim= e, > indicating that the symbol is not available for external use. >=20 > This isn't a perfect solution, as applications can still hack around it o= f 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= =20 the generated random number for allowing the calls to make within the libra= ry. i.e leverage the fact that external library would never know the random number generated=20 for the DPDK build and internal driver code does. > but I think it hits some of the high points, restricting symbol access fo= r any > library that prototypes its public and private symbols in the same header= file, > excluding the internal symbols from ABI constraints, and clearly document= ing > those symbols which we wish to limit to internal usage. >=20 > I've included a patch to the dpaa library to demonstrate its usage. If t= here is > consensus on this approach, I'll expand and repost the patch, pulling in = the > other libraries which have internal-only symbol usage. >=20 > Regards > Neil > Signed-off-by: Neil Horman > CC: Jerin Jacob Kollanukkaran > CC: Bruce Richardson > CC: Thomas Monjalon >=20