From: Dodji Seketeli <dodji@seketeli.org>
To: John Moon <quic_johmoo@quicinc.com>
Cc: <libabigail@sourceware.org>,
Trilok Soni <quic_tsoni@quicinc.com>,
"Satya Durga Srinivasu Prabhala" <quic_satyap@quicinc.com>
Subject: Re: abidiff improvements for kernel UAPI checker
Date: Fri, 22 Sep 2023 13:39:32 +0200 [thread overview]
Message-ID: <87fs36e8sr.fsf@seketeli.org> (raw)
In-Reply-To: <340b33bd-2b43-9f99-58e1-f1b77a51b48a@quicinc.com> (John Moon's message of "Mon, 24 Apr 2023 11:39:48 -0700")
Hello John,
John Moon <quic_johmoo@quicinc.com> a écrit:
[...]
> === Anonymous Enums ===
> Another issue that comes up when comparing ABI across wide swaths of
> kernel commit history are changes to anonymous enums. From what I can
> tell, there's not a great way to handle this. If someone adds a new
> anonymous enum, the tag abidiff gives (e.g. enum __anonymous_enum__6)
> can change, so abidiff reports a new anonymous enum with all the same
> fields even though it was basically just a "rename".
>
> For reference, this file is full of anonymous enums:
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/ethtool_netlink.h#L15.
> Basically any change in there is triggering a failure from the script.
[...]
Dodji Seketeli <dodji@seketeli.org> a écrit:
[...]
> I think we can do something similar to what we do for anonymous
> structs/unions, which it to consider content of the enums, rather than
> just their "made-up" names.
So, I have an initial implementation for handling the comparison of
anonymous enums and it's in the 'users/dodji/better-anon-enums' branch.
Maybe you can try this branch on your test case to see if you still have
issues regarding anonymous enums? If you still do, I'd be very much
interested in reproducing the issue locally on my system and extract a
smaller reproducer that could end up in the regression test suite of
libabigail.
I hope this can be useful somehow.
[...]
Cheers and many thanks!
--
Dodji
next prev parent reply other threads:[~2023-09-22 11:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 0:45 John Moon
2023-04-16 18:33 ` Trilok Soni
2023-04-21 18:21 ` Dodji Seketeli
2023-04-21 20:03 ` Dodji Seketeli
2023-04-24 18:39 ` John Moon
2023-05-10 14:21 ` Dodji Seketeli
2023-05-23 19:59 ` John Moon
2023-07-05 16:52 ` John Moon
2023-10-05 13:44 ` Support suppressing data members inserted right before flexible array members (was Re: abidiff improvements for kernel UAPI checker) Dodji Seketeli
2023-07-10 10:55 ` abidiff improvements for kernel UAPI checker Dodji Seketeli
2023-09-22 11:39 ` Dodji Seketeli [this message]
2023-09-22 11:51 ` Dodji Seketeli
2023-09-22 18:28 ` John Moon
2023-09-22 20:02 ` John Moon
2023-09-26 8:38 ` Dodji Seketeli
2023-09-27 17:37 ` John Moon
2023-09-29 9:52 ` Dodji Seketeli
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=87fs36e8sr.fsf@seketeli.org \
--to=dodji@seketeli.org \
--cc=libabigail@sourceware.org \
--cc=quic_johmoo@quicinc.com \
--cc=quic_satyap@quicinc.com \
--cc=quic_tsoni@quicinc.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).