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 D63A6A04F3; Thu, 19 Dec 2019 22:58:53 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B91F81BDFD; Thu, 19 Dec 2019 22:58:52 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 58F581BC25 for ; Thu, 19 Dec 2019 22:58:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576792729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4+39r8V1qB21Gk5/OXYvNU9Wo/nk7KFOKmK4FY7jdCw=; b=AUw+1m2kwyVEyWSAqCyOpBMG/y4KA/Z47+bIe7+EWZHEObWufA4Xu1vI3jkanhinqGarM6 7/yMzQ4HCSR7KT7tWivLxkYm4/1xRFj83R9L27lYxuwIxQ0zrtWNHl8VTh12AhbLGNE55R QosG9isKKimVGtkUekq3BAwosSGm8J0= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-131-5DCvxQP7MOGJyUNr282jHg-1; Thu, 19 Dec 2019 16:58:47 -0500 Received: by mail-vk1-f197.google.com with SMTP id l188so2399548vke.15 for ; Thu, 19 Dec 2019 13:58:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4+39r8V1qB21Gk5/OXYvNU9Wo/nk7KFOKmK4FY7jdCw=; b=ot1iVFn+F6WPLhBB71g+ob30XDMvWO+AlnwlQGSGiUNszbW6hv+Zf+UR6Z7AOtJAlz 8wBjU9pWY32xeAqf7eXTroC0o8dFZajpnzD8U2NcWp1k07eqqJ67htGe40SOnYAIoQSw 1fZ3oXEtroZRrWbicVqLiCar8AxhCtkNDfWttH63D+4tRROulq6dBcdLDXc+9iKxmEVr UPvr7ScNRACGjKhfjGAg2+n7LN/DtVYhQ5xSV97J+yu4HIStZE4wPU5WZZrZZPpPsHHa Ov0JTuVSjh3IzooT8jicJRl7duyaKysp5fwV9vmUFoCrgpvPss1BohPFwN4ZvwNw54io xoEw== X-Gm-Message-State: APjAAAVv/5LpgGW32natKbruTNiJ3bXq1N8+1roJCXXGTngQ+JqlmM5G 1OY/75VLVlI4b2OUFYAVaPTX4kd7nlofBChQ4cYw1/9RWfPcV5ebcaBaq3i7pIBKppdzz8hdoS8 XDakZyPn/mfPD3agTsDI= X-Received: by 2002:a1f:5385:: with SMTP id h127mr7590572vkb.56.1576792727194; Thu, 19 Dec 2019 13:58:47 -0800 (PST) X-Google-Smtp-Source: APXvYqyxOtlPmbc48lKPPgOknY+9B52NiYknQw2S+xs2djpyL/g5+f5rwytUnzPkwt/D9V/Jorp7publLks+TrFmimE= X-Received: by 2002:a1f:5385:: with SMTP id h127mr7590551vkb.56.1576792726758; Thu, 19 Dec 2019 13:58:46 -0800 (PST) MIME-Version: 1.0 References: <20191213140302.4252-1-kevin.laatz@intel.com> <20191213164110.9744-1-kevin.laatz@intel.com> In-Reply-To: <20191213164110.9744-1-kevin.laatz@intel.com> From: David Marchand Date: Thu, 19 Dec 2019 22:58:35 +0100 Message-ID: To: Kevin Laatz Cc: dev , Thomas Monjalon , Bruce Richardson , "Kinsella, Ray" , Tomasz Duszynski , Zyta Szpak , Rastislav Cernay , Aaron Conole X-MC-Unique: 5DCvxQP7MOGJyUNr282jHg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" Hello Kevin, On Fri, Dec 13, 2019 at 5:41 PM Kevin Laatz wrote: > > With the recent changes made to stabilize ABI versioning in DPDK, it will > become increasingly important to check patches for ABI compatibility. We > propose adding the ABI compatibility checking to be done as part of the > build. > > The advantages to adding the ABI compatibility checking to the build are > two-fold. Firstly, developers can easily check their patches to make sure > they don=E2=80=99t break the ABI without adding any extra steps. Secondly= , it > makes the integration into existing CI seamless since there are no extra > scripts to make the CI run. The build will run as usual and if an > incompatibility is detected in the ABI, the build will fail and show the > incompatibility. As an added bonus, enabling the ABI compatibility checks > does not impact the build speed. > > 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. > > The patches in this set include the ABI dump file generating script, the > dump files for drivers and libs, the meson option required to > enable/disable the checks, and the required meson changes to run the > compatibility checks during the build. > > Note: This patch set depends on: http://patches.dpdk.org/patch/63765/. T= he > generated .dump files in this patch set are based on the changes in the > patch "build: fix soname info for 19.11 compatibility". If a decision is > made to use a different format for the sonames, then a new version of thi= s > patch set will be required as the .dump files will need to be regenerated= . > > Note: The following driver dump files are not included in these patches: > common/mvep: missing dependency, "libmusdk" > net/mvneta: missing dependency, "libmusdk" > net/mvpp2: missing dependency, "libmusdk" > net/nfb: missing dependency, "libnfb" > crypto/mvsam: missing dependency, "libmusdk" > > They have not been included as I do not have access to these dependencies= . > Please feel free to add them if you can! (Maintainers of the above Cc'ed)= . - 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...). 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. - 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, Those last two points are still to be done. WDYT? 1: https://github.com/david-marchand/dpdk/commit/f18de2ec157f3cc1e7b319cb19= 700e1b5e9cecde 2: https://patchwork.dpdk.org/patch/63970/ -- David Marchand