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 0AF37A04F6;
	Fri, 20 Dec 2019 11:20:51 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id CD5231252;
	Fri, 20 Dec 2019 11:20:50 +0100 (CET)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 7CAE6235
 for <dev@dpdk.org>; Fri, 20 Dec 2019 11:20:48 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 5D6D822474;
 Fri, 20 Dec 2019 05:20:47 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute1.internal (MEProxy); Fri, 20 Dec 2019 05:20:47 -0500
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=mesmtp;
 bh=FriuJcaLfjk2Fi4pSZzB5o2STa2p3qkTNv7yR9eVE4A=; b=Dzu7sQbQNOYd
 W1y3ONjoAEjliqMmrB/zEZUMU2Ovm9Q8OBBj6HaaIPHgJbziI48RrANN/rUcgsoZ
 yyMWFTC5uthooiZcnY/2qPJdszDlA0FpF+0SrwIEY08SNbvsB5gc0bZ5ZbN4/F3d
 fjsMni3tg/NNwS6JGqBAVA6Dy83pAKc=
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=fm1; bh=FriuJcaLfjk2Fi4pSZzB5o2STa2p3qkTNv7yR9eVE
 4A=; b=GMv6ckbwVpilJrmgob9rGJm4ptE7A1AGZvBkvtCiAcwpU/sWytelhIwwd
 1V13d0nVpw4CKcWML5vcc0HhekVXZCqx1lh2fXkFuiiMC+vwkBETludidHQb2DVh
 SD6DQ1pZyjkJiT11wfx2dh2wyD8CH46gqBF8xy3xlnsIi1XatVfs0Dpy4SuVYMb4
 iMkM6++k0rtNP2hMyzx/CiGPmXZWd52BHRupJEEoXNNyeo0sGplO5Ve5xHl608GA
 DSAdmeaC9ydwVpnzq4V6L2dSK/GCykKGKEvdrtsMYfRlUKE1tfbr+K+mG8m3/QS0
 +Lc3MD2PDn2rN0Ql0kfK5XJqN1qOg==
X-ME-Sender: <xms:fqD8XQtsCM-S5J_uytmH6nkqQ_okZW0Vjgwwx4zIbIVOkuhFQfNHCg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddufedgudefucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff
 homhgrihhnpehgihhthhhusgdrtghomhdpughpughkrdhorhhgnecukfhppeejjedrudef
 gedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmoh
 hnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:fqD8XRvY8Hw8FzvoeCBb48jwkAFAltyWm8Equ5i1GLikywOJayWB7w>
 <xmx:fqD8XWwyQ_ktoYyjYR9JK1pZ9C-tg2YMQOPhrURD3qEN_r_ObL29TQ>
 <xmx:fqD8XXiJeLPm3SPQV-VygWlpf5eTdyFMD02d9qM345AKCTbAPrGDsQ>
 <xmx:f6D8XRn_5PblSTPIHZ_O2S8eyWg_FEbJ2GejYbCg74NRHw2at57M_w>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 5E6AB30608EA;
 Fri, 20 Dec 2019 05:20:45 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>,
 Kevin Laatz <kevin.laatz@intel.com>
Cc: dev <dev@dpdk.org>, Bruce Richardson <bruce.richardson@intel.com>,
 "Kinsella, Ray" <ray.kinsella@intel.com>, Tomasz Duszynski <tdu@semihalf.com>,
 Zyta Szpak <zr@semihalf.com>, Rastislav Cernay <cernay@netcope.com>,
 Aaron Conole <aconole@redhat.com>
Date: Fri, 20 Dec 2019 11:20:44 +0100
Message-ID: <1954775.STNsi1xJb4@xps>
In-Reply-To: <CAJFAV8xJaQoTYh9Q2rWkEcRU1fS0bLW=m-4SMmYptK0RDk_g8A@mail.gmail.com>
References: <20191213140302.4252-1-kevin.laatz@intel.com>
 <20191213164110.9744-1-kevin.laatz@intel.com>
 <CAJFAV8xJaQoTYh9Q2rWkEcRU1fS0bLW=m-4SMmYptK0RDk_g8A@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v6 00/11] Add ABI compatibility checks to the
	meson build
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>

19/12/2019 22:58, David Marchand:
> On Fri, Dec 13, 2019 at 5:41 PM Kevin Laatz <kevin.laatz@intel.com> wrote:
> > The proposed solution works as follows:
> > 1. Generate the ABI dump of the baseline. This can be done with the new
> >    script added in this set. This step will only need to be done when the
> >    ABI version changes (so once a year) and can be added to master so it
> >    exists by default. This step can be skipped if the dump files for the
> >    baseline already exist.
> > 2. Build with meson. If there is an ABI incompatibility, the build will
> >    fail and print the incompatibility information.
[...]
> - I asked for the dump files, but I can see that it is impractical.
> 
> The dump files are huge. I did not expect that :-).
> The dump files are architecture specific and maintaining multi arch
> dumps would be even bigger than just what you sent for x86_64.
> (not even considering the changes in ABI if some configuration items
> have an impact...).

I agree that dump files are better managed outside of git.


> As you pointed out, people who don't have all dependencies won't
> create/update those dump files.
> Dealing with ABI updates (thinking of bumping the ABI version) is
> likely a maintainer job, but it will be a source of issues and we
> (maintainers) might miss some updates especially for drivers we can't
> build.
> 
> 
> - Why do we restrict the checks to meson?
> The make build framework is going to disappear ok, but we can't leave
> it untested.
> People still rely on it.
> 
> Checking the ABI is orthogonal to building DPDK.
> Dumping the ABI and checking it against objects can be done externally.

I agree we should not rely on meson for running the check.


> - For those reasons, I have been trying an alternate approach [1]: in
> Travis, generate a reference dump based on the first ancestor tag,
> then build the proposed patches.
> All contributions get picked up by Aaron robot and would have to pass
> through this check.
> 
> As an exercise, I tried to integrate Eelco patch [2], that moves
> symbols from EXPERIMENTAL to a stable ABI. The check passes fine.
> I also tried to bump the ABI major version. The check fails, as
> expected, but I prepared a way to bypass such failures for the
> releases where we will explicitely break ABI.
> 
> For maintainers that integrate patches or developers that get a CI
> failure and want to fix it, we would need to help them to:
> * generate dumps on a reference version, so I would tend to write some
> documentation since playing with the current sources would be too
> dangerous from my pov,
> * run the checks, like adding the check in the
> devtools/test-*-build.sh scripts that already exist, with a new
> configuration item to point at the dumps per target,

We can start with a documented process,
and write a separate script later if we feel it helps.


> Those last two points are still to be done.
> 
> WDYT?
> 
> 
> 1: https://github.com/david-marchand/dpdk/commit/f18de2ec157f3cc1e7b319cb19700e1b5e9cecde
> 2: https://patchwork.dpdk.org/patch/63970/


Thanks to both of you trying some approaches and making progress.