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.