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 B2B87A05D3 for ; Thu, 23 May 2019 16:21:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A853B1B947; Thu, 23 May 2019 16:21:35 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 151281B947; Thu, 23 May 2019 16:21:33 +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 x4NEFJme029521; Thu, 23 May 2019 07:21:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=8wZQSCR5xKQrwa3Kf3b1BtLwmY04zbgkdf83GG3kBQQ=; b=noDZYSTb/wDWyx2CA/fdoo/o2Hf+auidr1GFLtdobmAfnCT5GOhlDEk3C2/0szPI8zLv mUEO2aSNqHynOkCxAd+8lbgw0guAaALIQctAto3jt15xHKpDRUsRKVvCvVjoVGBF4cC/ Tk2CbdSXDuLqH4FGSuzBVJnNGmiOWtFKoW6YkfhvW2DAQfGeiJN1Ae0JUhK9WiotoAeN BewbZeRdgEyT5QN31E2Ajhpqby7gxsz6Rcl9XmTgZcB5LIDIGPryQzDb4SiZK68TRqJF Xrk/sFtOLwQl1GxU9aoSsamSjOUmoP91CkRSx4DWqA2tuauY0FMRqBPQ0AS35YvQJokQ SQ== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 2snv44rbwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 23 May 2019 07:21:33 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 23 May 2019 07:21:32 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.53) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 23 May 2019 07:21:32 -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=8wZQSCR5xKQrwa3Kf3b1BtLwmY04zbgkdf83GG3kBQQ=; b=CYDXz4FZZmZDrGBwThJtJjq2+eVbW57eetP3H7LmsQyTpHt/Mi7md9PrmK02hx9p6oPFFeBbrRoIaIQXdMapvODKs9Wxbb3JIBcwyqL8XpE/ceJ+2a5hZjL+utaSvIYweMl/w8Yw/Wmm2HjjJseWzlwA/DVuSVkCxzlL2PKijCk= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2455.namprd18.prod.outlook.com (20.179.92.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Thu, 23 May 2019 14:21:30 +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.1922.018; Thu, 23 May 2019 14:21:30 +0000 From: Jerin Jacob Kollanukkaran To: Neil Horman CC: Bruce Richardson , "dev@dpdk.org" , "thomas@monjalon.net" , "stable@dpdk.org" Thread-Topic: [dpdk-dev] Re: [PATCH] devtools: skip the symbol check when map file under drivers Thread-Index: AdURcXZzvMt2pV+CRQK6U6d/KoJw1g== Date: Thu, 23 May 2019 14:21:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.201.57.97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a9eb10c-c10d-44d8-2f34-08d6df89f307 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR18MB2455; x-ms-traffictypediagnostic: BYAPR18MB2455: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00462943DE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(376002)(396003)(136003)(13464003)(199004)(189003)(64756008)(66446008)(76116006)(86362001)(102836004)(33656002)(3846002)(6116002)(66946007)(55016002)(476003)(66476007)(66556008)(5660300002)(9686003)(73956011)(14444005)(256004)(53546011)(68736007)(66066001)(99286004)(7696005)(52536014)(55236004)(53936002)(6506007)(4326008)(8676002)(26005)(8936002)(305945005)(316002)(81156014)(81166006)(14454004)(74316002)(6916009)(7736002)(229853002)(478600001)(54906003)(486006)(71190400001)(71200400001)(25786009)(186003)(6436002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2455; 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: 61vw3pq+l9yQjUk7fOLjPeO+Ts3hltVu+Kc/M4DrSx0OnRnbT/juAt+DPMpXitw6DZt/MsPKlNgM4MbqkJfCx3D0PkdLXajtJdcG2VtdTVLwHnLqrD35hzJzDQUWRgw98t7TjMIn9svm/Ifj8m/Dg+fCKg64fWzWiPwV06zPJx7hn+KZsmSquowejND14WnMTiX4FZhy1nGIXR8IL1xWaPoDcvYNWdigr/wkeDXpfSaDbo1aY6cxc4eUulSr1AzFY2b1kt1vdKpl8w0xkYsTclqKyFUwmGJ4k3JYMnC5c/NRs8v1wFM3zFrF5kev4yFX/cEqycSflEW6z/PK2id46995RJggOaqHNTZn1eHVTFxMUCcwXTIAdAOK41KscJLUPZmtgnv6R+iwsUjsoft5k88nX6JH9yaW8xWPo2TyQE8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2a9eb10c-c10d-44d8-2f34-08d6df89f307 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 14:21:29.8272 (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: BYAPR18MB2455 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-23_12:, , signatures=0 Subject: Re: [dpdk-stable] [dpdk-dev] Re: [PATCH] devtools: skip the symbol check when map file under drivers X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" > -----Original Message----- > From: Neil Horman > Sent: Thursday, May 23, 2019 12:29 AM > To: Jerin Jacob Kollanukkaran > Cc: Bruce Richardson ; dev@dpdk.org; > thomas@monjalon.net; stable@dpdk.org > Subject: Re: [EXT] Re: [dpdk-dev] Re: [PATCH] devtools: skip the symbol > check when map file under drivers > > > > > > IMO, The name prefix matters. The rte_* should denote it a > > > > > > DPDK API and application suppose to use it. > > > > > > > > > > > It doesn't, its just a convention. We have no documentation > > > > > that indicates what the meaning of an rte_* prefix is > > > > > specficially, above and beyond the fact thats how we name > > > > > functions in the DPDK. If you want to submit a patch to > > > > > formalize the meaning of function prefixes, you're welcome too > > > > > (though I won't support it, perhaps others will). But even if > > > > > you do, it doesn't address the underlying problem, which is that > applications still have access to those symbols. > > > > > Maintaining an ABI by assertion of prefix is really a lousy way > > > > > to communicate what functions should be accessed by an > > > > > application and which shouldn't. If a function is exported, and > > > > > included in the header file, people will try to use > > > > > > > > The current scheme in the driver/common is that, the header files > > > > are NOT made It as public ie not installed make install. > > > > The consumer driver includes that using relative path wrt DPDK > > > > source > > > directory. > > > > > > > Well, thats a step in the right direction. I'd still like to see > > > some enforcement to prevent the inadvertent use of those APIs though > > > > Yes header file is not exported. Not sure how a client can use those. > > Other than doing some hacking. > > > Yes, self prototyping the exported functions would be a way around that. > > > > > > > Anyway I will add experimental section to make tool happy. > > > > > > > That really not the right solution. Marking them as experimental is > > > just papering over the problem, and suggests to users that they will > > > one day be stable. > > > > That what my original concern. > > > > > What you want is to explicitly mark those symbols as internal only, > > > so that any inadvertent use gets flagged. > > > > What is your final thought? I can assume the following for my patch > > generation > > > > # No need to mark as experimental > > # Add @internal to denote it is a internal function like followed some = places > in EAL. > > > These are both correct, yes. >=20 > In addition, I would like to see some mechanism that explicitly marks the > function as exported only for the purposes of internal use. I understand= that > yours is a case in which this is not expressly needed because you don't > prototype those functions, but what I'd like to see is a macro in rte_com= pat.h > somewhere like this: >=20 > #define INTERNAL_USE_ONLY do {static_assert(0, "Function is only availabl= e > for internal DPDK usage");} while(0) >=20 > so that, in your exported header file (of which I'm sure you have one, ev= en if > it doesn't contain your private functions, you can do something like this= : >=20 > #ifdef BUILDING_RTE_SDK > void somefunc(int val); > #else > #define somefunc(x) INTERNAL_USE_ONLY > #endif I think, We have two cases 1) Internal functions are NOT available via DPDK SDK exported header files 2) Internal functions are available via DPDK SDK exported header files I think, you are trying to address case 2( as case 1 is not applicable in t= his context due lack of header file) For case 2, IMO, the above scheme will not be enough as=20 The consumer entity can simply add the exact C flags to skip that check in = this case, -DBUILDING_RTE_SDK. IMO, it would be correct remove private functions from public header files.= No strong options on this. =20 >=20 > This combination allows for 'internal' functions to be used (defining int= ernal > to mean access to functions only when building the DPDK SDK), while > expressly breaking the build of any application which attempts to use the= se > functions when not building the SDK (i.e. when building an application th= at > expects to link to the DPDK after its built). Again, I uderstand that in= your > case, it may be sufficient to just not prototype the functions you don't = want > used, but I think in the general case its important to have some mechanis= m > to expressly prevent their usage outside the SDK >=20 > Best > Neil >=20 > > > > > > Neil > > > > > > > > > >