lkml.org 
[lkml]   [2020]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2020-07-19 20:26    [W:2.457 / U:1.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site