public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@seketeli.org>
To: John Moon via Libabigail <libabigail@sourceware.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	 Nathan Chancellor <nathan@kernel.org>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	"Nicolas Schier" <nicolas@fjasle.eu>,
	 John Moon <quic_johmoo@quicinc.com>,
	 <linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	 <linux-arm-kernel@lists.infradead.org>,
	<linux-arm-msm@vger.kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Randy Dunlap <rdunlap@infradead.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	 Bjorn Andersson <andersson@kernel.org>,
	Todd Kjos <tkjos@google.com>,
	 Matthias Maennich <maennich@google.com>,
	Giuliano Procida <gprocida@google.com>,
	 <kernel-team@android.com>, Jordan Crouse <jorcrous@amazon.com>,
	 Trilok Soni <quic_tsoni@quicinc.com>,
	 Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>,
	 Elliot Berman <quic_eberman@quicinc.com>
Subject: Re: [PATCH v2 1/2] check-uapi: Introduce check-uapi.sh
Date: Fri, 03 Mar 2023 22:09:11 +0100	[thread overview]
Message-ID: <87zg8t5yq0.fsf@seketeli.org> (raw)
In-Reply-To: <20230301075402.4578-2-quic_johmoo@quicinc.com> (John Moon via Libabigail's message of "Tue, 28 Feb 2023 23:54:01 -0800")

Hello John,

John Moon via Libabigail <libabigail@sourceware.org> a écrit:

> While the kernel community has been good at maintaining backwards
> compatibility with kernel UAPIs, it would be helpful to have a tool
> to check if a commit introduces changes that break backwards
> compatibility.
>
> To that end, introduce check-uapi.sh: a simple shell script that
> checks for changes to UAPI headers using libabigail.
>
> libabigail is "a framework which aims at helping developers and
> software distributors to spot some ABI-related issues like interface
> incompatibility in ELF shared libraries by performing a static
> analysis of the ELF binaries at hand."
>
> The script uses one of libabigail's tools, "abidiff", to compile the
> changed header before and after the commit to detect any changes.
>
> abidiff "compares the ABI of two shared libraries in ELF format. It
> emits a meaningful report describing the differences between the two
> ABIs."
>
> The script also includes the ability to check the compatibilty of
> all UAPI headers across commits. This allows developers to inspect
> the stability of the UAPIs over time.

Thank you for working on this.

The libabigail bits look good to me, for what it's worth.  I just have
some general considerations to discuss.

[...]

> +# Perform the A/B compilation and compare output ABI
> +compare_abi() {

[...]

> +	if "$ABIDIFF" --non-reachable-types "${ref_header}.bin" "${base_header}.bin" > "$log"; then
> +		printf "No ABI differences detected in %s from %s -> %s\n" "$file" "$ref" "${base_ref:-dirty tree}"
> +	else
> +		# If the only changes were additions (not modifications to existing APIs), then
> +		# there's no problem. Ignore these diffs.
> +		if grep "Unreachable types summary" "$log" | grep -q "0 removed" &&
> +		   grep "Unreachable types summary" "$log" | grep -q "0 changed"; then
> +			return 0

There is no problem in parsing the output of the tool like this.
However, the return code of the tool has been designed as a bit field that
could be analysed to know more about the kind of changes that were
reported: https://sourceware.org/libabigail/manual/abidiff.html#return-values.

Right now, there is no bit assigned to detect new types (or interface)
addition, but do you think that it would be a helpful new feature to add
to abidiff for this use case?  We can discuss this in a separate thread
if you prefer, so that we don't pollute others with this minutiae.

> +		fi
> +		{
> +			printf "!!! ABI differences detected in %s from %s -> %s !!!\n\n" "$file" "$ref" "${base_ref:-dirty tree}"
> +			sed  -e '/summary:/d' -e '/changed type/d' -e '/^$/d' -e 's/^/  /g' "$log"

Here again, if you'd like to have a particular output format emitted by
the tool, we'd be glad to discuss how to improve the plasticity of the
tool enough to emit the right output for you.  For instance, we could
add a new --no-summary that would let the tool display the change
directly without the summary header that you are strimming out with this
sed script.

[...]

Thanks again for this tool that I think might be very useful.

Cheers,

-- 
		Dodji

  reply	other threads:[~2023-03-03 21:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-01  7:54 [PATCH v2 0/2] Validating UAPI backwards compatibility John Moon
2023-03-01  7:54 ` [PATCH v2 1/2] check-uapi: Introduce check-uapi.sh John Moon
2023-03-03 21:09   ` Dodji Seketeli [this message]
2023-03-05  4:22   ` Masahiro Yamada
2023-03-05 17:08     ` John Moon
2023-03-01  7:54 ` [PATCH v2 2/2] docs: dev-tools: Add UAPI checker documentation John Moon
2023-03-05  6:20   ` Masahiro Yamada
2023-03-06 16:56     ` John Moon
2023-03-01 17:50 ` [PATCH v2 0/2] Validating UAPI backwards compatibility Nick Desaulniers
2023-03-01 18:03   ` John Moon
2023-03-01 19:24     ` John Moon
2023-03-01 22:33       ` John Moon
2023-03-01 23:33         ` Nick Desaulniers
2023-03-01 23:35           ` Trilok Soni
2023-03-01 23:52         ` Mark Wielaard
2023-03-01 23:59           ` John Moon
2023-03-10  8:09 ` Christoph Hellwig
2023-03-10 18:20   ` Trilok Soni
2023-03-20  6:26     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zg8t5yq0.fsf@seketeli.org \
    --to=dodji@seketeli.org \
    --cc=andersson@kernel.org \
    --cc=arnd@arndb.de \
    --cc=gprocida@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jorcrous@amazon.com \
    --cc=kernel-team@android.com \
    --cc=libabigail@sourceware.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maennich@google.com \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=quic_eberman@quicinc.com \
    --cc=quic_johmoo@quicinc.com \
    --cc=quic_satyap@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=rdunlap@infradead.org \
    --cc=tkjos@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).