Mixing Rust and C in Linux likened to cancer by kernel maintainer
- Reference: 1738796972
- News link: https://www.theregister.co.uk/2025/02/05/mixing_rust_and_c_linux/
- Source link:
Concerns surfaced last September when Microsoft software engineer Wedson Almeida Filho [1]stepped away from the [2]Rust for Linux project , citing frustration with "nontechnical nonsense" – which is one way to describe the difficulty of collaborating with those who have different goals.
Don't force me to deal with your shiny language of the day. Maintaining multi-language projects is a pain
The issue flared again last month, when a [3]proposed abstraction to allow Rust-written device drivers to call the primarily C-based kernel's core [4]DMA API met resistance from kernel maintainer Christoph Hellwig.
Specifically, [5]a patch was submitted that would allow Rust drivers to use the DMA API's dma_alloc_coherent() C function to allocate and map large memory regions for direct memory access by hardware.
In a message to the Linux kernel mailing list, Hellwig [6]wrote : "No Rust code in kernel/dma, please." For what it's worth, the patch added code to the [7]rust/kernel portion of the Linux source tree, not [8]kernel/dma , as far as we can tell.
[9]
Miguel Ojeda of the Rust for Linux project asked Hellwig to suggest an alternative.
[10]
[11]
Hellwig replied: "Keep the wrappers in your code instead of making life painful for others," and went on to argue that "interfaces to the DMA API should stay in readable C code and not in weird bindings so that it [remains] greppable and maintainable." Hellwig's wish seems to be that non-C drivers have their own private bindings to C code, and that these abstractions are not maintained separately, not even in the rust/kernel tree.
Challenged by Danilo Krummrich, a Red Hat software engineer involved in the Rust for Linux project, Hellwig makes clear that he's just not keen to deal with Rust code.
[12]
"Don't force me to deal with your shiny language of the day," he [13]wrote . "Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I'm concerned."
In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.
But Hellwig doesn't appear to be interested in having DMA Rust abstractions maintained separately. He [14]explained that he does not want another maintainer:
If you want to make Linux impossible to maintain due to a cross-language codebase, do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not Rust itself, just to escape the flameware brigade).
Students of tech history may recall that Linux itself was likened to cancer by former Microsoft CEO Steve Ballmer in 2001. "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches," Ballmer [15]said , back before Linux had metastasized into the Windows Subsystem for Linux.
Hellwig went on to argue that having others maintain the Rust abstraction layer for the DMA coherent allocator as a separate component doesn't improve matters and hinders kernel maintainability:
Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favorite language it's definitely one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.
Hector Martin, project lead of Ashai Linux, [16]shared his belief that Hellwig's remarks constitute a Code of Conduct violation but doubts any disciplinary action would be taken. The Register asked Martin whether he intends to file a Code of Conduct complaint, and we've not heard back.
[17]Upgrading Linux with Rust looks like a new challenge. It's one of our oldest
[18]Keep calm and learn Rust: We'll be seeing a lot more of the language in Linux very soon
[19]CISA looked at C/C++ projects and found a lot of C/C++ code. Wanna redo any of it in Rust?
[20]Google says replacing C/C++ in firmware with Rust is easy
Martin argues that the Rust for Linux developers should ignore Hellwig's concerns and submit their patch for approval by kernel boss Linus Torvalds:
"If Linus doesn't pipe up with an authoritative answer to this thread, Miguel and the other Rust folks should just merge this series once it is reviewed and ready, ignoring Christoph's overt attempt at sabotaging the project. If Linus [accepts the pull request], what Christoph says doesn't matter. If Linus doesn't [accept it], the [Rust for Linux] project is essentially dead until either Linus or Christoph make a move. Everything else is beating around the bush."
[21]
The Register asked Hellwig whether he wished to comment for this article and he declined. We also sought comment from Linux Foundation Fellow Greg Kroah-Hartman, who has not responded.
The case for Rust
The Linux kernel added support for Rust code [22]on October 3, 2022 , shortly after Microsoft Azure CTO Mark Russinovich [23]argued that new programming projects should be written in Rust rather than C or C++.
"For the sake of security and reliability, the industry should declare those languages as deprecated," Russinovich said.
His rationale is that Rust code can be written to avoid the memory safety bugs (eg, buffer overflows) that plague C and C++ code and represent the majority of serious vulnerabilities in large projects. That view has since attracted the support of [24]government security organizations around the world.
There are people who just don't like the notion of Rust, and having Rust encroach on their area
Those who write C and C++ code have taken note of the growing interest in Rust and acknowledged that memory safety concerns need to be addressed. Hence there are numerous projects underway, like [25]TrapC , [26]FilC , [27]Mini-C , and [28]Safe C++ that aim to make C and C++ less vulnerable to memory bugs, in addition to efforts like DARPA's [29]TRACTOR to automatically convert C code to Rust.
Shortly after Filho announced his departure from Rust for Linux last year, Linux honcho Linus Torvalds addressed the friction between C and Rust developers at the Linux Foundation's Open Source Summit in Vienna, Austria.
"Clearly, there are people who just don't like the notion of Rust, and having Rust encroach on their area," Torvalds [30]said . "People have even been talking about the Rust integration being a failure … We've been doing this for a couple of years now so it's way too early to even say that, but I also think that even if it were to become a failure – and I don't think it will – that's how you learn."
So far, the Linux developer community has learned that Rust isn't always welcome. ®
Get our [31]Tech Resources
[1] https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/
[2] https://rust-for-linux.com/
[3] https://lore.kernel.org/rust-for-linux/20250108122825.136021-1-abdiel.janulgue@gmail.com/
[4] https://docs.kernel.org/core-api/dma-api-howto.html
[5] https://lore.kernel.org/rust-for-linux/20250108122825.136021-3-abdiel.janulgue@gmail.com/#Z31rust:kernel:dma.rs
[6] https://lore.kernel.org/lkml/20250108135951.GA18074@lst.de/
[7] https://github.com/torvalds/linux/tree/master/rust/kernel
[8] https://github.com/torvalds/linux/tree/master/kernel/dma
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z6RB9lT_NBH7OIo9fHu0ngAAAdQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z6RB9lT_NBH7OIo9fHu0ngAAAdQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z6RB9lT_NBH7OIo9fHu0ngAAAdQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z6RB9lT_NBH7OIo9fHu0ngAAAdQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] https://lore.kernel.org/lkml/20250110083955.GA5395@lst.de/
[14] https://lore.kernel.org/lkml/20250128092334.GA28548@lst.de/
[15] https://www.theregister.com/2001/06/02/ballmer_linux_is_a_cancer/
[16] https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
[17] https://www.theregister.com/2024/09/09/opinion_column_rust_linux/
[18] https://www.theregister.com/2021/11/10/where_rust_fits_into_linux/
[19] https://www.theregister.com/2024/06/28/cisa_open_source/
[20] https://www.theregister.com/2024/09/06/google_rust_c_code_language/
[21] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z6RB9lT_NBH7OIo9fHu0ngAAAdQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[22] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8aebac82933ff1a7c8eede18cab11e1115e2062b
[23] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[24] https://www.theregister.com/2024/11/08/the_us_government_wants_developers/
[25] https://www.theregister.com/2024/11/12/trapc_memory_safe_fork/
[26] https://www.theregister.com/2024/11/16/rusthaters_unite_filc/
[27] https://www.theregister.com/2025/01/03/mini_c_microsoft_inria/
[28] https://www.theregister.com/2024/09/16/safe_c_plusplus/
[29] https://www.theregister.com/2024/08/03/darpa_c_to_rust/
[30] https://www.theregister.com/2024/09/19/torvalds_talks_rust_in_linux/
[31] https://whitepapers.theregister.com/
"it would suck"
I'm not sure how rewriting a C kernel in a C-like language with strict compile-time safety would make it suck. It might suck in that porting/converting millions of lines of kernel code is going to take some time, and in that time, the new kernel will be incomplete.
But like low-level C, Rust compiles down into GC-less machine code. It might even run faster in places as some run-time safety checks/mechanisms can be performed at build time.
I suppose we should just call Rust what it is. Ada fan fiction.
C.
Re: "it would suck"
Here's the thing.
I don't much like Rust. "strict compile-time safety" is magical thinking. Software is the state of the hardware, and hardware has bugs.
At some point a language that lets you force what you want into the correct shape and alignment for the use case, is desirable.
It's purely a desperate attempt to make Rust language relevant to anybody who's not a masochist.
Not magical thinking
I like Rust. But I like Zig more because Zig just lets me code without Rust's obstinance, and with some safety, but not as much as Rust's.
Rust's compile-time safety is absolutely non-magical thinking. Have you encountered the borrow checker? No doubt there are ways to trick your way past it, or just turn it off with unsafe{}. But by and large, it's going to stop you doing silly things at build time - and it cannot be bargained with.
The underlying hardware is irrelevant IMHO. The masochism is very relevant.
C.
Re: "it would suck"
The Linux codebase doesn't exist in isolation, it's a function of the community around it. Porting the codebase to a language that is familiar to a tiny minority of that community is what would cause the damage, all those folks who aren't familiar with the new language are frozen out of the development effort - and all their domain knowledge is effectively lost with it. Thus the result would *likely* not be as good / useful to people as the original codebase (ie: it would be incomplete and it would suck balls). Ultimately it's a daft argument to have - Linus, bless him, appears to be more pragmatic.
Knew it.
Embrace, Extend, Estinguish.
Say what?
The Linux kernel added support for Rust code on October 3, 2022, shortly after Microsoft Azure CTO Mark Russinovich argued that new programming projects should be written in Rust rather than C or C++.
Since when has the utterings of a Microsoft lackey had any bearing on Linux kernel development?
Re: Say what?
"Since when has the utterings of a Microsoft lackey had any bearing on the Linux kernel's overall development?"
FTFY
The answer is never.
Need I point out to the readers of this august rag that Microsoft has been contributing to the kernel for years? And not in Rust, either ...
Re: Say what?
We're not saying they are necessarily connected. If they were connected, we would have said so. We're saying that around the time the Linux kernel project was opening the door to Rust, the Azure CTO was remarking how good the language is for security and reliability.
From that you can infer Rust was at the time getting more recognition and support.
C.
This is the scariest part of all this, IMO
> Hector Martin, project lead of Ashai Linux, shared his belief that Hellwig's remarks constitute a Code of Conduct violation
Shameful. Kernel devs calling for disciplinary action 'cause they don't like someone's take on a technical subject?! If you read the thread quoted (https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/) there's no cursing or anything but Christian's dissenting opinion (and his reasons for having it), but nah, let's just cancel-culture a sentiment Hector doesn't like.
Re: This is the scariest part of all this, IMO
I thought the same thing when I read that sentence, and to some extent I still think so. However, thinking more about the message, it's an announcement that he plans to sabotage someone else's work, not because it has a technical flaw, but because he doesn't like it. If I was a maintainer and someone submitted a patch for a piece of hardware, and I tried to prevent it being merged because I don't use that hardware and I don't want to worry if my future changes might break it, it would not be productive. Linux works as a project because developers agree to work in such a way that they don't break other parts, considering compatibility with parts they haven't written. The Rust developers aren't telling the maintainers that they must also write their contributions in Rust, but they are asking for the same compatibility that developers of other components are expected to provide.
Code of conduct seems like the wrong way to categorize this, but that doesn't mean that it is a completely justifiable approach to development.
Old man yells at cloud
Darn y'all millenials with yer 'mammary safety' and 'borrow checkin'. Why back in my day, we just backed up right over the edge of a signed char array we was using to hold a complex struchoor, and it didn't hurt us none. Wall sometimes thar was a segfault, and if the party were REALLY goin' on, a kernel fault, but joo know what? We LIKED it thet way. You damn kids with your 'seatbelts' and 'airbags' and 'mebbe we shouldn't just trust devs to catch all possible mammary axis vi-oh-lay-shuns because obviously most don't even usually try.' WELL BOO HOO, buttercup. We've whipped this thang into pretty plumb good shape, just a few scuffs from when it went off the road (we may have bin drinkin') and every now 'n' than we bolt somethin' to the side and whoops... kernel fault! And we go 'tsk tsk shudder coulder woulder caught thet!' But then ah goes back to mah desk, ah does, and ah press mah fingers to mah lips, smirk, and go 'tee hee hee hee hee.' Ahhh, good times, good times.
Yes, definitely an interesting thread read...
Especially https://lore.kernel.org/lkml/Z6OzgBYZNJPr_ZD1@phenom.ffwll.local/
I can see why a maintainer may not want a shim of the C API that he is currently responsible for in another language, as it adds a reverse dependency that he will need to consider and possibly maintain when adding or changing his API.
Maybe a rule change to explicitly state that a reverse dependency is not his responsibility but the sole responsibility of the project adding that dependency.
IMHO Hector needs to try to be a bit more understanding and constructive.
Why not port the a LTS kernel to rust? Probably because it would suck spaceballs.