Re: Rust kernel policy

[Miguel Ojeda]

On Tue, Feb 18, 2025 at 10:49 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> I have a few issues with Rust in the kernel:
>
> 1. It seems to be held to a *completely* different and much lower standard than the C code as far as stability. For C code we typically require that it can compile with a 10-year-old version of gcc, but from what I have seen there have been cases where Rust level code required not the latest bleeding edge compiler, not even a release version.

Our minimum version is 1.78.0, as you can check in the documentation.
That is a very much released version of Rust, last May. This Thursday
Rust 1.85.0 will be released.

You can already build the kernel with the toolchains provided by some
distributions, too.

I think you may be referring to the "unstable features". There remain
just a few language features (which are the critical ones to avoid
source code changes), but upstream Rust is working to get them stable
as soon as possible -- the Linux kernel has been twice, in 2024H2 and
2025H1, a flagship goal of theirs for this reason:

    https://rust-lang.github.io/rust-project-goals/2025h1/goals.html#flagship-goals
    https://rust-lang.github.io/rust-project-goals/2024h2/index.html

Meanwhile that happens, upstream Rust requires every PR to
successfully build a simple configuration of the Linux kernel, to
avoid mistakenly breaking us in a future release. This has been key
for us to be able to establish a minimum version with some confidence.

This does not mean there will be no hiccups, or issues here and there
-- we are doing our best.

> 2. Does Rust even support all the targets for Linux?

Rust has several backends. For the main (LLVM) one, there is no reason
why we shouldn't be able to target everything LLVM supports, and we
already target several architectures.

There is also a GCC backend, and an upcoming Rust compiler in GCC.
Both should solve the GCC builds side of things. The GCC backend built
and booted a Linux kernel with Rust enabled a couple years ago. Still,
it is a work in progress.

Anyway, for some of the current major use cases for Rust in the
kernel, there is no need to cover all architectures for the time
being.

> 3. I still feel that we should consider whether it would make sense to compile the *entire* kernel with a C++ compiler. I know there is a huge amount of hatred against C++, and I agree with a lot of it – *but* I feel that the last few C++ releases (C++14 at a minimum to be specific, with C++17 a strong want) actually resolved what I personally consider to have been the worst problems.

Existing Rust as a realistic option nowadays, and not having any
existing C++ code nor depending on C++ libraries, I don't see why the
kernel would want to jump to C++.

> As far as I understand, Rust-style memory safety is being worked on for C++; I don't know if that will require changes to the core language or if it is implementable in library code.

Rust-style memory safety for C++ is essentially the "Safe C++"
proposal. My understanding is that C++ is going with "Profiles" in the
end, which is not Rust-style memory safety (and remains to be seen how
they achieve it). "Contracts" aren't it, either.

My hope would be, instead, that C is the one getting an equivalent
"Safe C" proposal with Rust-style memory safety, and we could start
using that, including better interop with Rust.

> David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage.

That is great, but that does not give you memory safety and everyone
would still need to learn C++.

Cheers,
Miguel