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 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddufedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhdpughpughkrdhorhhgnecukfhppeejjedrudef gedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmoh hnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 5E6AB30608EA; Fri, 20 Dec 2019 05:20:45 -0500 (EST) From: Thomas Monjalon To: David Marchand , Kevin Laatz Cc: dev , Bruce Richardson , "Kinsella, Ray" , Tomasz Duszynski , Zyta Szpak , Rastislav Cernay , Aaron Conole Date: Fri, 20 Dec 2019 11:20:44 +0100 Message-ID: <1954775.STNsi1xJb4@xps> In-Reply-To: References: <20191213140302.4252-1-kevin.laatz@intel.com> <20191213164110.9744-1-kevin.laatz@intel.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Archived-At: List-Archive: 19/12/2019 22:58, David Marchand: > On Fri, Dec 13, 2019 at 5:41 PM Kevin Laatz 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.