[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f449ed0a-8142-121c-6af9-3fbdff1b517b@redhat.com>
Date: Thu, 15 Dec 2016 14:35:36 +0100
From: Stanislav Kozina <skozina@...hat.com>
To: Nicholas Piggin <npiggin@...il.com>,
Hannes Frederic Sowa <hannes@...hat.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Don Zickus <dzickus@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ben Hutchings <ben@...adent.org.uk>,
Michal Marek <mmarek@...e.com>,
Adam Borowski <kilobyte@...band.pl>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Debian kernel maintainers <debian-kernel@...ts.debian.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported from
asm
> Yeah it's great work, so is Stanislav's checker. I wouldn't mind having
> a kernel-centric checker tool merged in the kernel if it is small,
> maintained, and does a sufficient job for distros.
I'd be very happy to see the resulting tool in the kernel tree, as it
needs to be kept in sync with any significant changes done to the kernel
layout in the future.
It's not important if the result is based off libabigail or kabi-dw
code, I'm sure both can be adjusted to serve the needs. kabi-dw tends to
be smaller and still rather proof-of-concept, libabigail is definitely
more mature. The only real difference is C vs. C++ code.
> So if I understand where we are, moving the ABI compatibility checking
> to one of these tools looks possible. What to do when we have an ABI change
> is not settled, but feeding version numbers explicitly into modversions
> is an option that would be close to what distros do today.
Sounds great!
Thank you!
-Stanislav
Powered by blists - more mailing lists