Date:   Sun, 19 Jul 2020 21:19:19 +0300
From:   Adrian Bunk <bunk@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Josh Triplett <josh@...htriplett.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        alex.gaynor@...il.com, geofft@...reload.com, jbaublitz@...hat.com,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: Linux kernel in-tree Rust support

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

Powered by blists - more mailing lists