On Thu, Jul 16, 2020 at 03:06:01PM +0200, Arnd Bergmann wrote:
>
> I would expect we'd want a fairly tight coupling between kernel
> releases and minimum rust releases at first. Whatever is the latest
> stable rust version during the kernel's merge window might be
> assumed to be the minimum version for the life of that kernel, but
> an LTS release would not suddenly start relying on features
> from a newer compiler (thought it might warn about known bugs).
>
> This might mean that linux-next requires a beta version of rust, if
> the release is expected before the merge window and it contains
> an important change.
I would expect this is absolutely not wanted,
it would make testing recent kernels very hard.
If you want to keep a tool that tightly to the kernel,
please bundle it with the kernel and build it as part
of the kernel build.
I would suggest to start with a proper design/specification what the
kernel wants to use, so that you are confident that a compiler
implementing this will be sufficient for the next 5 years.
As a secondary benefit, starting with a proper design often brings
a better result than adding permanent features piece by piece.
As a tertiary benefit, it would avoid tying the kernel to one specific
compiler implementation. A compiler like mrustc or a hypothetical Rust
frontend for gcc could then implement a superset of what the kernel
needs.
> Staying with fairly recent versions of clang
> certainly helped in getting clang and the kernel to co-evolve and
> get to the point we are now in using it as an alternative to gcc.
The main difference is between an alternative to an existing tool,
and a mandatory new tool.
> While Linux used to build with 12 year old compilers (4.1 until
> 2018), we now require a 6 year old gcc (4.9) or 1 year old
> clang/llvm. I don't know whether these will fully converge over
> time but it seems sensible that the minimum rust frontend version
> we require for a new kernel release would eventually also fall
> in that range, requiring a compiler that is no more than a few
> years old, but not requiring the latest stable release.
The correct range for a mandatory tool are the 6 to 12 years for gcc.
Debian stable and Ubuntu LTS are providing (different) mechanisms
for installing the kernel from the next stable/LTS release 2 years
later[1] for supporting new hardware.
If kernel 5.12 LTS cannot be compiled on Ubuntu 20.04 LTS with
the 2019 gcc 9 there would be pain downstream.
In the embedded world spreads far wider than these 3 years are common.
I would currently have a real-life usecase for compiling a recent
kernel with a gcc 4.0 (sic) toolchain.
Properly supporting 15 year old toolchains would be painful upstream,
supporting 6 year old toolchains is a reasonable compromise between
not being too painful upstream while rarely causing pain downstream.
What applies to gcc does also apply to other external tools used
during the kernel build.
> Arnd
cu
Adrian
[1] following a new upstream kernel stable branch every 6 months (Ubuntu)
or the latest upstream stable kernels (Debian) until this is reached
