Messages in this thread | | | Date | Mon, 10 Apr 2023 20:45:46 +0200 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH v5 1/2] check-uapi: Introduce check-uapi.sh |
| |
On Mon, Apr 10, 2023 at 07:03:05PM +0900, Masahiro Yamada wrote: > On Sat, Apr 8, 2023 at 5:35 AM John Moon <quic_johmoo@quicinc.com> wrote: > > > > 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 compatibility of > > all UAPI headers across commits. This allows developers to inspect > > the stability of the UAPIs over time. > > > > Signed-off-by: John Moon <quic_johmoo@quicinc.com> > > > > BTW, is there anybody (except the submitters) who loves this tool? > (or anybody who has ever evaluated this?)
I evaluated the first one, and yes, I do want this, but I haven't tested it out yet, sorry.
I get patches for header files all the time and hand-verifying that they don't break the abi is a pain at times
> According to this tool, it looks like we broke a lot of UAPI > headers in the previous MW (between v6.2 and v6.3-rc1).
That's not ok, and needs to be fixed, otherwise this is useless as no one can rely on it at all.
> The script takes some time because it builds many objects > internally. > > However, once this script starts running, you must not hit Ctrl-C. > If you do it, your repository will be sprinkled with a ton > of untracked files.
That needs to be unwound and fixed.
> CAVEAT > This tool runs 'git checkout' a couple of times internally. > If you interrupt it, your worktree might be messed up.
ctrl-c can be properly caught and the git state needs to be restored for this to be able to be accepted.
thanks,
greg k-h
| |