Message-ID: <Y0g8HEYHZYHGdwlf@sirena.org.uk>
Date:   Thu, 13 Oct 2022 17:26:04 +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 Thu, Oct 13, 2022 at 09:23:36AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 13, 2022 at 01:59:52PM +0100, Mark Brown wrote:

> > 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.

> The thing is, do we really want to be catering to this? In the first
> place, enterprise users and enterprise kernels are already doing freaky
> things, forked to no end. But moreover, do we actually want to support

My understanding with that use case was that it was precisely people who
were happy enough with a disro userspace but wanted something more
mainline for their kernel for whatever reason but quite often involving
not having all the fun enterprise patching.  One use case I've heard of
is doing semi-embedded stuff where you need kernel support for the
hardware but everything exciting in userspace is locally developed
software.

> people building the kernel with a different compiler than most of us
> develop with? In a basic way, that just seems like a recipe for
> disaster.

Personally I do frequently use my distro compiler FWIW.

> It's also easy, nearly trivial, to download toolchains. Arnd provides a
> bunch with his crosstool. "Must use a toolchain from your distro" is a
> requirement that affects nobody.

I wouldn't be so sure about that if you express the requirement as
"must have control over and reproducability for the build environment"
instead, it's a lot easier to get everything by installing distro
packages than to have to introduce custom steps (having packaged
versions of things even if not provided by the distro themselves helps
here).  It's not that it's impossible for people to get things set up
but it's definitely a barrier - I know there's a bunch of projects I
should look at but don't do anything with precisely because it's too
much work to figure out how to install and keep up to date whatever
shiny new build dependencies they're requiring without messing up any of
the distro provided stuff.  Those do tend to be things other than the
basic C compiler though.

> So I just think we're thinking about this all wrong. It doesn't matter
> what's available on the distros. It matters what the most reasonable
> compiler to develop with is, first of all. And secondly, it matters that
> this compiler is easily available for users to download in a variety of
> settings need-be. And I'm pretty sure this latter part is already the
> case.

There's definitely tarballs for the kernel side stuff which is fine for
development use, I'm not aware of packaged versions.  There are things
like tuxmake which will run the builds in containers which is another
approach to the problem, though again that'd require people to control
both the tool version and the container versions which might not be much
of a win compared to dealing with tarballs.

> Plus, as I mentioned earlier, this is already the model we're going
> toward by virtue of Rust (and to a small extent, Clang) invading.

Yeah, like I say I suspect that the way we handle dependencies for those
might change if people were using those things without actively seeking
them out.  You can flip things around and say that the reason we're
happy to upgrade the base requirement for clang is that people using it
are actively seeking it out already so there's not the demand for
working with older versions.  At least for me it also helps that clang
provides apt repositories for current versions.

Note that I'm not saying we shouldn't upgrade our requirements at all,
just that I'm worrying about going from one extreme to the other in
terms of version requirements - it feels like there's a step change when
you move from things you can get in current release distros people are
likely to be using to things that will require a large proportion of
people to install extra stuff.  At the minute we're more at the other
end where it can be hard to figure out who'd even have the oldest
versions we support without deliberately seeking them out and keeping
them going is noticably making work for people.

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

Powered by blists - more mailing lists