From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2DF9EA0598; Tue, 21 Apr 2020 19:35:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4C9A91D17F; Tue, 21 Apr 2020 19:35:32 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 57EB41D17D for ; Tue, 21 Apr 2020 19:35:30 +0200 (CEST) IronPort-SDR: tg4ZzhV7cDUgbmsGuK13NXCBv/CM32Ufli70XwzWwcTkaxvBAIGg9WeS/r+4PBDBKaNh3N9HNJ lFnnHaogKS5A== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2020 10:35:29 -0700 IronPort-SDR: DLAJje7Eb0yGEsY9sQB5yEnhECZWVVpl265DOrwCsTETENdCNwD+GOeWXJHgKNU9kPCOWv68/M 0gnpSOjBghUw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="429606099" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga005.jf.intel.com with ESMTP; 21 Apr 2020 10:35:27 -0700 Received: from irsmsx603.ger.corp.intel.com (163.33.146.9) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Apr 2020 18:35:26 +0100 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by irsmsx603.ger.corp.intel.com (163.33.146.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 21 Apr 2020 18:35:25 +0100 Received: from shsmsx603.ccr.corp.intel.com ([10.109.6.143]) by SHSMSX603.ccr.corp.intel.com ([10.109.6.143]) with mapi id 15.01.1713.004; Wed, 22 Apr 2020 01:35:23 +0800 From: "Wang, Haiyue" To: Thomas Monjalon , David Marchand CC: Neil Horman , dev , "Burakov, Anatoly" , Vamsi Attunuru , Jerin Jacob Kollanukkaran , "Yigit, Ferruh" , "Richardson, Bruce" , "Kinsella, Ray" Thread-Topic: [PATCH v8 0/2] support for VFIO-PCI VF token interface Thread-Index: AQHWFafaI2Lui2Y2EEyeOUOuYmQWTqiBtuGAgACHcqD//347AIAAjE3A//973ACAAQnooP//hLAAABDTtmD//+e4AP/+6L4A Date: Tue, 21 Apr 2020 17:35:23 +0000 Message-ID: <9b9ae2775c68421c971686f454df20b9@intel.com> References: <20200305043311.17065-1-vattunuru@marvell.com> <5346011.DvuYhMxLoT@thomas> <2714716.e9J7NaK4W3@thomas> In-Reply-To: <2714716.e9J7NaK4W3@thomas> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v8 0/2] support for VFIO-PCI VF token interface 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: Thomas Monjalon > Sent: Tuesday, April 21, 2020 16:48 > To: David Marchand ; Wang, Haiyue > Cc: Neil Horman ; dev ; Burakov, Ana= toly > ; Vamsi Attunuru ; Jeri= n Jacob Kollanukkaran > ; Yigit, Ferruh ; Richardson,= Bruce > ; Kinsella, Ray > Subject: Re: [PATCH v8 0/2] support for VFIO-PCI VF token interface >=20 > 21/04/2020 04:52, Wang, Haiyue: > > From: Thomas Monjalon > > > 21/04/2020 03:38, Wang, Haiyue: > > > > From: Thomas Monjalon > > > > > 20/04/2020 19:37, Wang, Haiyue: > > > > > > From: Thomas Monjalon > > > > > > > 20/04/2020 19:02, Wang, Haiyue: > > > > > > > > From: David Marchand > > > > > > > > > I had a look at the CI, I can see we are still missing bi= ts to handle > > > > > > > > > the ABI failure on rte_vfio_setup_device. > > > > > > > > > > > > > > > > Yes, not handle it now. > > > > > > > > > > > > > > > > If 'rte_vfio_setup_device' can be internal, not official DP= DK API, then __rte_internal > > > > > > > > is the best way to handle ABI issue. > > > > > > > > > > > > > > Please could you help finishing integration of __rte_internal= ? > > > > > > > > > > > > I thought it should be Neil ? "Yes, I'll get back to this today= " ;-) > > > > > > > http://inbox.dpdk.org/dev/CAJFAV8ydLkV0afEHqbh6KeA3Box0Yxb3N0MNGtMD4S9bmS= gT0A@mail.gmail.com/ > > > > > > > > > > It did not happen after several months. > > > > > If you want to unblock your patches, I think it is safer to finis= h yourself. > > > > > > > > > > > > > Unfortunately, this __rte_internal will still make the ci fail to r= un when move the function > > > > to INTERNAL session: > > > [...] > > > > +INTERNAL { > > > > + global: > > > > + > > > > + # added in 20.05 > > > > + rte_vfio_setup_device; > > > > +}; > > > > > > Why do you need to move the symbol explicitly in .map? > > > The tool should ignore symbols moving to internal, as an exception un= til 20.11. > > > > If not move the symbol explicitly in .map, another kind of error happen= ed. > > > > ./devtools/check-abi.sh old_abi new_abi > > Functions changes summary: 0 Removed, 1 Changed, 0 Added function > > Variables changes summary: 0 Removed, 0 Changed, 0 Added variable > > > > 1 function with some indirect sub-type change: > > > > [C] 'function int rte_vfio_setup_device(const char*, const char*, int= *, vfio_device_info*)' at > eal_vfio.c:704:1 has some indirect sub-type changes: > > parameter 5 of type 'unsigned char*' was added > > > > Error: ABI issue reported for 'abidiff --suppr ./devtools/libabigail.ab= ignore --no-added-syms -- > headers-dir1 old_abi/include --headers-dir2 new_abi/include old_abi/dump/= librte_eal.dump > new_abi/dump/librte_eal.dump' >=20 > This is what I said: you need to add a rule to ignore internal symbols. >=20 Got the kind reply from Dodji, the maintainer of libabigail, his suggestion meets what we have done for 'EXPERIMENTAL'. So it seems that have to mark all needed functions as INTERNAL firstly, which obviously will break the CI as the public functions are removed.... " __PROJECT_INTERNAL_USE_ONLY_VERSION__ { global: funA }; ... Then, once you have all your internal functions marked in the ELF binary with the proper ELF version string, you can tell libabigail to suppress all functions that have that version by writing a suppression specification file that has this content: [suppress_function] symbol_version =3D __PROJECT_INTERNAL_USE_ONLY_VERSION__ "