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

On 2/3/2020 2:00 PM, Dodji Seketeli wrote:

Hello,

Ferruh Yigit [off-list ref] a écrit:

[...]

quoted

+1 the change/shuffle of the existing values are problematic, but we don't have
it in this case.

Right.

[...]

quoted

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.

quoted

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,