Message-ID: <a7c5973a-497c-4f31-a7be-b3123bddb6dd@zytor.com>
Date: Tue, 18 Feb 2025 16:58:27 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>, David Airlie <airlied@...il.com>,
        linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On 2/18/25 14:54, Miguel Ojeda wrote:
> On Tue, Feb 18, 2025 at 10:49 PM H. Peter Anvin <hpa@...or.com> 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.
> 

So at this point Rust-only kernel code (other than experimental/staging) 
should be deferred to 2034 -- or later if the distributions not included 
in the "same" are considered important -- if Rust is being held to the 
same standard as C.

> 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.

Well, these cases predated 2024 and the 1.78 compiler you mentioned above.

>> 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.

That is of course pushing the time line even further out.

>> 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++.

You can't convert the *entire existing kernel code base* with a single 
patch set, most of which can be mechanically or semi-mechanically 
generated (think Coccinelle) while retaining the legibility and 
maintainability of the code (which is often the hard part of automatic 
code conversion.)

Whereas C++ syntax is very nearly a superset of C, Rust syntax is 
drastically different -- sometimes in ways that seem, at least to me, 
purely gratuitous. That provides a huge barrier, both technical (see 
above) and mental.

>> 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.

So, in other words, another long horizon project... and now we need 
people with considerable expertise to change the C code.

>> 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++.

The point is that C++ is a superset of C, and we would use a subset of 
C++ that is more "C+"-style. That is, most changes would occur in header 
files, especially early on. Since the kernel uses a *lot* of inlines and 
macros, the improvements would still affect most of the *existing* 
kernel code, something you simply can't do with Rust.

It is, however, an enabling technology. Consider the recent introduction 
of patchable immediates. Attaching them to types allows for that to be a 
matter of declaration, instead of needing to change every single call 
site to use a function-like syntax.

	-hpa

Powered by blists - more mailing lists