Message-ID: <Y0gLyLbdOCetX5LN@sirena.org.uk>
Date:   Thu, 13 Oct 2022 13:59:52 +0100
From:   Mark Brown <broonie@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-toolchains@...r.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: gcc 5 & 6 & others already out of date?

On Wed, Oct 12, 2022 at 07:36:40PM -0600, Jason A. Donenfeld wrote:

> But also, it's not just Rust. Clang support has been an incremental
> thing, and the kernel has dropped old Clang versions as they no longer
> make sense. Heck, the new KCFI implementation requires bleeding edge

I suspect that if clang starts being the default system compiler for one
of the distros with longer support windows we'll start treating it more
like GCC, right now clang is in the position where for the most part
people using clang are actively seeking it out and explicitly picking a
clang version rather than just trying to build the kernel with whatever
compiler they got by default.

> And then there's old trusty gcc. Gcc also improves according to a nice
> cadence, and we know people are using later gccs because nobody is
> catching the build errors from old gccs. So let's stop pretending we
> support old compilers. We clearly don't. Maybe some subset of code
> does, but by and large, I doubt many developers are actually daily
> driving gcc 5.1 and doing allyesconfig builds with it. Yes, many are
> rightfully cautious of gcc 12 and stick with gcc 11 still, and that's
> reasonable, but 11 or even 10 is still way larger than 5.1.

> The truth is, people tend to use more recent toolchains. And if Clang
> hasn't broken the will of the stranglers, then surely Rust will.

The expected users for old toolchains was always users doing something
like building a newer kernel on an old enterprise distro rather than
people actually developing anything AIUI.

> So, what are your thoughts on just abandoning this charade all
> together, and saying that we support the last 2 or 3 releases of a
> compiler (and related toolchain - binutils and such) at the time of

Two or three releases seems a bit ambitious, I'm sitting here in front
of a Debian stable system which probably has another year or so of being
the latest release left and it's sitting at GCC 10.2 with the latest
release of GCC being 12.2.  Probably also worth noting that GCC did a
9.5 release in May this year as it went out of their support window.

> the kernel's release, and admit that our C is a moving target, just as
> our Rust inevitably will be. Then we don't have to have these tortured
> conversations every few years about 4.9 or 5.1 or 6.3 or whatever
> enterprise [il-]logic has tended to dictate how things have worked
> until now.

> As usual, feel free to chase me off with pitchforks. I'm sure some
> RHEL folks hate this. But I think it's at least worth consideration.

I do think it would be helpful to track where the choices of baseline
versions are coming from, if nothing else that'd probably make the
conversations about upgrading them easier even if we don't actually bump
them until we run into trouble.

A quick look suggests that RHEL 7 is at GCC 4.8 (so running into trouble
anyway), RHEL 8 at 8.x, SLES looks like it makes newer compilers
available even for the old releases (eg, there's GCCs up to 10 available
for SLES 12 AFAICT).  Ubuntu 16.04 does seem to use GCC 5 but it's on
extended security support at this point, their 18.04 is at GCC 7.4 from
the looks of it.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists