Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 2/3/2020 2:00 PM, Dodji Seketeli wrote:
> Hello,
> 
> Ferruh Yigit <ferruh.yigit@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,
>