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 DE93CA052E; Mon, 3 Feb 2020 17:12:03 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A9EA1BFE1; Mon, 3 Feb 2020 17:11:44 +0100 (CET) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by dpdk.org (Postfix) with ESMTP id 5210C1BF99 for ; Mon, 3 Feb 2020 15:00:53 +0100 (CET) X-Originating-IP: 91.166.131.130 Received: from localhost (91-166-131-130.subs.proxad.net [91.166.131.130]) (Authenticated sender: dodj@seketeli.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 0A1B81BF21B; Mon, 3 Feb 2020 14:00:50 +0000 (UTC) Received: by localhost (Postfix, from userid 1001) id C8DAF1A068D; Mon, 3 Feb 2020 15:00:48 +0100 (CET) From: Dodji Seketeli To: Ferruh Yigit Cc: Neil Horman , "Ananyev\, Konstantin" , Thomas Monjalon , Akhil Goyal , "Trahe\, Fiona" , David Marchand , Anoob Joseph , "Kusztal\, ArkadiuszX" , "dev\@dpdk.org" , "Richardson\, Bruce" , "Mcnamara\, John" , Andrew Rybchenko , "aconole\@redhat.com" Organization: Me, myself and I References: <20191220152058.10739-1-david.marchand@redhat.com> <6121442.K2JlShyGXD@xps> <1779027.taCxCBeP46@xps> <666f2cc7-0906-7a07-a582-87800f321a00@intel.com> <20200203115034.GA25978@hmswarspite.think-freely.org> <0054d684-2637-f7b9-f256-6cb80f4a19c3@intel.com> X-Operating-System: Red Hat Enterprise Linux Server 7.7 X-URL: http://www.seketeli.net/~dodji Date: Mon, 03 Feb 2020 15:00:48 +0100 In-Reply-To: <0054d684-2637-f7b9-f256-6cb80f4a19c3@intel.com> (Ferruh Yigit's message of "Mon, 3 Feb 2020 13:09:54 +0000") Message-ID: <86ftfr3h4f.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 03 Feb 2020 17:11:40 +0100 Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks 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, Ferruh Yigit a =C3=A9crit: [...] > +1 the change/shuffle of the existing values are problematic, but we don'= t have > it in this case. Right. [...] > The concern is when there are cases we can waive, we can't directly rely = on the > tool and automate it. These indicators good for improving the code, but n= ot good > to use it as build time checker. Well, it depends. The tooling as it is today have the capability to automatically "waive" some classes of A{B,P}I change reports that you guys (the developers) deem harmless, in the context of your project. For instance, in the precise case of interest here, one could define a "suppression specification" to teach the ABI verifier that, for the enum rte_crypto_asym_xform_type, the only enumerator which numerical value is allowed to change is the one named RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END. The content of the suppression specification file would look like: [suppress_type] # So, in practise, this rule is to allow adding enumerators # only to the of the the rte_crypto_asym_xform_type enum, # right before the RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END # enumerator which is meant to always be the last enumerator. type_kind =3D enum name =3D rte_crypto_asym_xform_type changed_enumerators =3D RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END This way, you can hopefully reduce the surface of the changes you want to see reported, tailored in a way that is specific to your project. This should hopefully bring the system closer to a state that would allow you guys to having something that is automated enough to have it be triggered at build time. And if there is some sensibly needed tweaking that the libabigail tooling doesn't allow you guys to do right away, I'd be happy to hear about it and try to add the functionality to the framework for you guys. > Is there any way to reduce the failure only to definite ABI breakages? I hope my comment above somewhat answers this question of yours. If it does not, please tell me. Cheers, --=20 Dodji