From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id C7E0CA0588;
	Tue, 21 Apr 2020 10:47:54 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id C2FCC1252;
	Tue, 21 Apr 2020 10:47:53 +0200 (CEST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 6D2A51C235
 for <dev@dpdk.org>; Tue, 21 Apr 2020 10:47:52 +0200 (CEST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47])
 by mailout.nyi.internal (Postfix) with ESMTP id E6CA55C01C6;
 Tue, 21 Apr 2020 04:47:51 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Tue, 21 Apr 2020 04:47:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm1; bh=
 Ohjo4OWDnFm9/40msmpkslYkxc+y1Fpu+bP4O/Z0Dg0=; b=SKpzXd8xoxiQlKS4
 eBw2l+p+s5PrPh0kJ5m286vUAZKuxbYKE9cdACKIdcPPGxpy1SN8gCcLb7u4r2C5
 4RxKE7ui0gFwRXDWedCirQ0QW/W+W/svh/5H75M2MsvYOteQL4coUxVchcEPdPjG
 Kmm1uSdkmjXj/xSyr8A/j93WAzRO9XdK4UAA6pBMxYkEhesrh2qXlYcol445IQmg
 nHLXJghUsGOPidjY+WSFR6Mdg6CZ0Bdd+Av2DKi382axxvgkmAYk1REIeuYqyF6O
 3b+lzWesLvpJC2pTTo4hmVihyyWJPfPExYFG+Q4BNw599QBsUFCNtfXNcd9GNN9E
 XI/rDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm2; bh=Ohjo4OWDnFm9/40msmpkslYkxc+y1Fpu+bP4O/Z0D
 g0=; b=qo3ECCMk2smMZOooVU1FRg6HtHmPTorWF73govR6Ic3jRtsp1pmoPiaWN
 KfbIjD2W9cD+QGu/aeKR2AAJZEWAziIs4nkTC13URx07TOhsjn8b1XpwdISLpdro
 3zlM6eEgBGBr//eTu7Pd4MbYBZtgFfSxWiISjuDPZfYabKV66p8X80uW8x5SBOeq
 kCpKdaaFdLVB6XMrSg8JiWTkoWJ7iORZtHB7C7zLcWFSSJxTrATG2/XC9w66bzAY
 0Z3u/hXkPS5zgKYnXGjx4g2zffUrrkKNWz+DalUa4LszMrnNh+mnUKhiCFnJq971
 1XCZ0p1t+bTdW93RZG55kR0rwMCvw==
X-ME-Sender: <xms:N7OeXmRDbyTG6Y2sbAs4cqzX9n5MigakHBENX4aE8Iysj7fckRsoSQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgddtkecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh
 hmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefgedrvddtfedrudekgeenucev
 lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrsh
 esmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:N7OeXhLnLe3l4Fwt8INacnumpIDaczNEzq7CA-jCUBccfLqfhbpWQg>
 <xmx:N7OeXgSR4a15UZC_Cq-vRDyhF_45unxh9zNCNsHSWvl2cXuYPx9hgg>
 <xmx:N7OeXnLoRP1Ajado3m_KBotiQZeqhiucidY1CjHw851xXV7f_58-og>
 <xmx:N7OeXqjuYWUOOG-5zu1YdPOmTWRZqdCMrmc-wQJL2HxV5bJtiD9ZBA>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 2F4EC328006F;
 Tue, 21 Apr 2020 04:47:50 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>, "Wang,
 Haiyue" <haiyue.wang@intel.com>
Cc: Neil Horman <nhorman@tuxdriver.com>, dev <dev@dpdk.org>, "Burakov,
 Anatoly" <anatoly.burakov@intel.com>, Vamsi Attunuru <vattunuru@marvell.com>,
 Jerin Jacob Kollanukkaran <jerinj@marvell.com>, "Yigit,
 Ferruh" <ferruh.yigit@intel.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>, "Kinsella, Ray" <ray.kinsella@intel.com>
Date: Tue, 21 Apr 2020 10:47:48 +0200
Message-ID: <2714716.e9J7NaK4W3@thomas>
In-Reply-To: <caa18c2a56d441748ddb924914e5fd02@intel.com>
References: <20200305043311.17065-1-vattunuru@marvell.com>
 <5346011.DvuYhMxLoT@thomas> <caa18c2a56d441748ddb924914e5fd02@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <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>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

21/04/2020 04:52, Wang, Haiyue:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 21/04/2020 03:38, Wang, Haiyue:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 20/04/2020 19:37, Wang, Haiyue:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > 20/04/2020 19:02, Wang, Haiyue:
> > > > > > > From: David Marchand <david.marchand@redhat.com>
> > > > > > > > I had a look at the CI, I can see we are still missing bits 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 DPDK 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/CAJFAV8ydLkV0afEHqbh6KeA3Box0Yxb3N0MNGtMD4S9bmSgT0A@mail.gmail.com/
> > > >
> > > > It did not happen after several months.
> > > > If you want to unblock your patches, I think it is safer to finish yourself.
> > > >
> > >
> > > Unfortunately, this __rte_internal will still make the ci fail to run 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 until 20.11.
> 
> If not move the symbol explicitly in .map, another kind of error happened.
> 
> ./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.abignore --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'

This is what I said: you need to add a rule to ignore internal symbols.