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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 26 Apr 2021 20:18:19 +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 Mon, Apr 26, 2021 at 2:31 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> I think the Rust proponents should be open to the fact that their
> work will eventually depend on themselves or someone else
> fixing a working compiler for the maintained architectures in
> the Linux kernel one way or the other, so they will be able to
> work with Rust project anywhere in the kernel.
>
> For example m68k is not going away. Avoiding this question
> of compiler support, just waiting and hoping that these old
> architectures will disappear is the wrong idea. The right idea
> is to recognize that LLVM and/or GCC Rust needs to
> support all these architectures so they can all use Rust.
> Someone needs to put in the effort.

The RFC does not avoid the question -- please note it explicitly
mentions the architecture/platform support issue and the current
dependency on LLVM, as well as the possible ways to solve it.

We would love to not have that issue, of course, because that would
enable Rust to be used in other parts of the kernel where it is likely
to be quite useful too.

But even if we did not have the issue today, it seems like starting
with drivers and other "leaf" modules is a better approach. There are
several reasons:

  - If for reason reason we wanted to remove Rust from the kernel,
then it would be easier to do so if only "leaf" bits had been written.

  - We cannot compile the Rust support without nightly features yet,
so it does not seem wise to make it a hard requirement right away.

  - Kernel developers need time to learn a bit of Rust, thus writing
subsystems or core pieces of the kernel in Rust would mean less people
can understand them.

Given that drivers are a big part of the new code introduced every
release, that they are "leaf" modules and that in some cases they are
only intended to be used with a given architecture, they seem like a
good starting point.

Cheers,
Miguel