Re: [PATCH v5 1/2] check-uapi: Introduce check-uapi.sh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/13/2023 7:37 AM, Mark Wielaard wrote:
Hi,

On Wed, 2023-04-12 at 09:37 -0700, John Moon via Libabigail wrote:
On 4/11/2023 11:14 PM, Greg Kroah-Hartman wrote:
Would you find the tool more useful if it simply filtered out all instances
where the size of the type did not change? This would filter out the
following which the tool currently flags:

- enum expansions
- reserved field expansions
- expansions of a struct with a flex array at the end
- type changes
- re-ordering of existing members
- ...others?

Obviously not, as some of those are real breakages, and some are not at
all.

Please understand what is an abi breakage.  Adding new enums is not.
Using a reserved field is not.  Reording existing members IS.


Yes, understood that method would miss certain classes of breakages. I
was suggesting it as a way to improve the signal-to-noise ratio of the
tool since we don't currently have an algorithm for determining
breakages with 100% accuracy.

Note that you can check the exit code of libabigail's abidiff to see
whether something is an incompatible abi change or not, see:
https://sourceware.org/libabigail/manual/abidiff.html#return-values

You can also of course use suppressions to instruct abidiff to avoid
reporting changes involving certain ABI artifacts:
https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppr-spec-label

Cheers,

Mark

Checking the ABIDIFF_ABI_INCOMPATIBLE_CHANGE flag in the return code is a good idea, but checking it doesn't change what the tool is currently outputting (i.e. the flag is set for all the changes currently reported). I think this is because of some filtering we're doing based on grepping stdout, but checking the return code would be more stable.

The suppressions may work for some cases, but I fear they would be too eager in other cases. Looking at the docs, I'm not sure how we could express something like:

"suppress changed enumerators if they end in 'MAX' or 'LAST' and appear at the end of the enumeration"

or

"suppress data member insertions into a struct if the last member in the struct has its size reduced by sizeof(new_member) and is named 'pad' or 'reserved'"

They're complicated cases to detect in a general way.

Thanks,
John



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux