[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bb60fe817f5144929a527d1f5768dd1a@AcuMS.aculab.com>
Date: Mon, 8 Mar 2021 09:39:42 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Josh Poimboeuf' <jpoimboe@...hat.com>,
Masahiro Yamada <masahiroy@...nel.org>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Michal Marek <michal.lkml@...kovi.net>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
"Linux Kbuild mailing list" <linux-kbuild@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Justin Forbes <jforbes@...hat.com>,
Ondrej Mosnacek <omosnace@...hat.com>,
Frank Eigler <fche@...hat.com>,
Kees Cook <keescook@...omium.org>
Subject: RE: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT
modules
> - "External modules must be built with the same GCC version"
>
> As has been stated repeatedly, by Linus and others, there's no
> technical reason behind this claim. It ignores the realities of how
> distros release the kernel and compiler independently, with separate
> cadences. Minor variances in compiler version are ABI compatible.
Aren't major versions ABI compatible?
Otherwise it is a different architecture.
> Also, for features which are dependent on compiler version, many of
> those are now enabled by kbuild. As I suggested to you previously,
> kbuild should warn when such features get disabled (which can happen
> due to a compiler/toolchain change or due to a .config copied from
> another system).
Anything that is just an optimisation (or pessimisation) really
doesn't matter.
AFAICT most of these options are in the latter category.
One think people might do is download a kernel from kernel.org
and then build an extra module for it.
The compiler they have will be completely different.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists