The drama surrounding Rust code within the Linux kernel continues… Christoph Hellwig is the maintainer of the DMA mapping helpers and several other areas of the kernel has been an outspoken critic of Rust code or secondary programming languages within the Linux kernel kernel. Hellwig has been critical of Rust code for the Linux kernel and its long-term maintainability. Today he’s out with another mailing list post where he notes that Linus Torvalds mentioned in private he would override maintainer vetoes on Rust code within the kernel.
The latest on Hellwig’s perspective of Rust code within the Linux kernel is below. Some interesting insight from a dissenting view. The thread in full can be found on the Rust for Linux mailing list.
“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”
The mailing list thread is in relation to this Rust for Linux policy page attempting to define the Rust kernel policy.
