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 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefgedrvddtfedrudekgeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrsh esmhhonhhjrghlohhnrdhnvght X-ME-Proxy: 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 To: David Marchand , "Wang, Haiyue" Cc: Neil Horman , dev , "Burakov, Anatoly" , Vamsi Attunuru , Jerin Jacob Kollanukkaran , "Yigit, Ferruh" , "Richardson, Bruce" , "Kinsella, Ray" Date: Tue, 21 Apr 2020 10:47:48 +0200 Message-ID: <2714716.e9J7NaK4W3@thomas> In-Reply-To: References: <20200305043311.17065-1-vattunuru@marvell.com> <5346011.DvuYhMxLoT@thomas> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 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.