Re: Rust kernel policy

[Christoph Hellwig <hch@infradead.org>]

On Sun, Feb 09, 2025 at 09:56:35PM +0100, Miguel Ojeda wrote:
> Hi all,
> 
> Given the discussions in the last days, I decided to publish this page
> with what our understanding is:
> 
>     https://rust-for-linux.com/rust-kernel-policy
> 
> I hope it helps to clarify things. I intend to keep it updated as needed.

I don't think having a web page in any form is useful.  If you want it
to be valid it has to be in the kernel tree and widely agreed on.

It also states factually incorrect information.  E.g.

"Some subsystems may decide they do not want to have Rust code for the
time being, typically for bandwidth reasons. This is fine and expected."

while Linus in private said that he absolutely is going to merge Rust
code over a maintainers objection.  (He did so in private in case you
are looking for a reference).

So as of now, as a Linux developer or maintainer you must deal with
Rust if you want to or not.

Where Rust code doesn't just mean Rust code [1] - the bindings look
nothing like idiomatic Rust code, they are very different kind of beast
trying to bridge a huge semantic gap.  And they aren't doing that in a
few places, because they are showed into every little subsystem and
library right now.

So we'll have these bindings creep everywhere like a cancer and are
very quickly moving from a software project that allows for and strives
for global changes that improve the overall project to increasing
compartmentalization [2].  This turns Linux into a project written in
multiple languages with no clear guidelines what language is to be used
for where [3].  Even outside the bindings a lot of code isn't going to
be very idiomatic Rust due to kernel data structures that intrusive and
self referencing data structures like the ubiquitous linked lists.
Aren't we doing a disservice both to those trying to bring the existing
codebase into a better safer space and people doing systems programming
in Rust?

Having worked on codebase like that they are my worst nightmare, because
there is a constant churn of rewriting parts from language A to language
B because of reason X and then back because of reason Z.  And that is
without the usual "creative" Linux process of infighting maintainers.

I'd like to understand what the goal of this Rust "experiment" is:  If
we want to fix existing issues with memory safety we need to do that for
existing code and find ways to retrofit it.  A lot of work went into that
recently and we need much more.  But that also shows how core maintainers
are put off by trivial things like checking for integer overflows or
compiler enforced synchronization (as in the clang thread sanitizer).
How are we're going to bridge the gap between a part of the kernel that
is not even accepting relatively easy rules for improving safety vs
another one that enforces even strong rules.

If we just want to make writing drivers easier a new language for that
pushes even more work and increases the workload on the already
overworked people keeping the core infrastructure in shape.

So I don't think this policy document is very useful.  Right now the
rules is Linus can force you whatever he wants (it's his project
obviously) and I think he needs to spell that out including the
expectations for contributors very clearly.

For myself I can and do deal with Rust itself fine, I'd love bringing
the kernel into a more memory safe world, but dealing with an uncontrolled
multi-language codebase is a pretty sure way to get me to spend my
spare time on something else.  I've heard a few other folks mumble
something similar, but not everyone is quite as outspoken.


[1] I've written and worked on a fair bit of userspace Rust code, but
I'm not an expert by any means, so take this with a grain of salt

[2] The idea of drivers in eBPF as done by HID also really doesn't help
with that as much as I like eBPF for some use cases

[3] Unless Linus forces it onto your subsystem, or Dave decides anything
touching Nvidia hardware must be in Rust of course