On 2/3/2020 2:00 PM, Dodji Seketeli wrote: > Hello, > > Ferruh Yigit <ferruh.yi...@intel.com> a écrit: > > [...] > >> +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 not >> 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 = enum > name = rte_crypto_asym_xform_type > changed_enumerators = 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.
Thanks, at least this provides a way to silence the warnings not an issue for us as we hit them. Is there a more global, don't warn on new enums kind of option? Although I assume this is not possible since _END or _MAX enum value will be changing and tool can't know its usage and will report the change. > > 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, >