linux-kernel - Re: [PATCH 00/13] [RFC] Rust support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Apr 2021 05:10:09 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Wedson Almeida Filho <wedsonaf@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/13] [RFC] Rust support

On Tue, Apr 27, 2021 at 1:13 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> Actually my reply to Wedson brought up a new issue, which is the
> quality of learning resources and the lack of an equivalent to
> The C Programming Language book.

I recall having a similar feeling when initially jumping into
individual chapters of The Rust Programming Language book. I think it
is intended to be read from cover to cover instead.

There are other resources, see [1]. For instance, there is The
Embedded Rust Book [2]. Some of those are a WIP, but perhaps others
can recommend better finished/published books.

In any case, Rust has more features than C, some of them quite unique,
and they are routinely used, so it does take some time to learn.

[1] https://www.rust-lang.org/learn
[2] https://docs.rust-embedded.org/book/

> I think a good starting point would be to either fix Rust support in
> GCC or implement some more important ISAs in LLVM,
> whichever is easiest. I don't mind having just *one* compiler but
> I mind having *a* compiler for every arch we support.
>
> [...]
>
> Portability to old systems and ISAs is a virtue in itself
> because of the effect it has on code quality, not necessarily
> for the support itself.

I agree that there are benefits of keeping compiler technology
flexible, but one cannot force or expect any project (including the
Linux kernel) to maintain all code forever.

In the end, we need to balance that adaptability against the benefits
of adding Rust. In particular because nowadays LLVM is able to cover
the majority of devices that want to run the very latest Linux
kernels. Thus those benefits apply to most users. If LLVM only
supported, say, x86_64, I would agree that it would not be enough.

By contrast, compiler flexibility only matters indirectly to users,
and at some point there are diminishing returns to keeping all
architectures around.

In any case, adding Rust (in particular for "leaf" modules) does not
imply that we will lose those architectures any time soon. That would
take at least several years, and would require quite a few things to
happen at the same time:

  - That Rust got so widely used in the kernel (because the benefits
turned out to be important) that maintainers went as far as wanting to
drop C drivers from mainline for Rust equivalents.

  - That GCC did not get any way to compile Rust (no Rust frontend for
GCC, no GCC backend for `rustc`, etc.) and, moreover, that the plans
for that had been dropped.

  - That LLVM did not add support for the missing architectures.

The first point is unlikely any time soon. The second point is
unlikely, too, given there is funding for that now (and I assume those
projects will receive more support if Rust lands in the kernel). The
third point is likely, though.

Cheers,
Miguel