[dpdk-dev] [PATCH v2 4/4] add ABI checks
Ferruh Yigit
ferruh.yigit at intel.com
Mon Feb 3 15:46:40 CET 2020
On 2/3/2020 2:00 PM, Dodji Seketeli wrote:
> Hello,
>
> Ferruh Yigit <ferruh.yigit at 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,
>
More information about the dev
mailing list