Rust, a modern and notably more memory-safe language than C, once seemed like it was on a steady, calm, and gradual approach into the Linux kernel.
In 2021, Linux kernel leaders, like founder and leader Linus Torvalds himself, were impressed with the language but had a "wait and see" approach. Rust for Linux gained supporters and momentum, and in October 2022, Torvalds approved a pull request adding support for Rust code in the kernel.
By late 2024, however, Rust enthusiasts were frustrated with stalls and blocks on their efforts, with the Rust for Linux lead quitting over "nontechnical nonsense." Torvalds said at the time that he understood it was slow, but that "old-time kernel developers are used to C" and "not exactly excited about having to learn a new language." Still, this could be considered a normal amount of open source debate.
But over the last two months, things in one section of the Linux Kernel Mailing List have gotten tense and may now be heading toward resolution—albeit one that Torvalds does not think "needs to be all that black-and-white." Greg Kroah-Hartman, another long-time leader, largely agrees: Rust can and should enter the kernel, but nobody will be forced to deal with it if they want to keep working on more than 20 years of C code.
Previously, on Rust of Our Lives
Earlier this month, Hector Martin, the lead of the Asahi Linux project, resigned from the list of Linux maintainers while also departing the Asahi project, citing burnout and frustration with roadblocks to implementing Rust in the kernel. Rust, Martin maintained, was essential to doing the kind of driver work necessary to crafting efficient and secure drivers for Apple's newest chipsets. Christoph Hellwig, maintainer of the Direct Memory Access (DMA) API, was opposed to Rust code in his section on the grounds that a cross-language codebase was painful to maintain.
Torvalds, considered the "benevolent dictator for life" of the Linux kernel he launched in 1991, at first critiqued Martin for taking his issues to social media and not being tolerant enough of the kernel process. "How about you accept that maybe the problem is you," Torvalds wrote.
But then Hellwig posted a longer missive, outlining his opposition to Rust bindings—or translations of Rust libraries that can work with equivalents in C—and continuing with his prior comparison of such multi-language allowances to "cancer." "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," Hellwig wrote. He also stated that Torvalds had "in private said that he absolutely is going to merge Rust code over a maintainers [sic] objection."
A two-way “wall of protection”
Torvalds' response from Thursday does offer some clarification on Rust bindings in the kernel, but also on what die-hard C coders can and cannot control.
Maintainers like Hellwig who do not want to integrate Rust do not have to. But they also cannot dictate the language or manner of code that touches their area of control but does not alter it. The pull request Hellwig objected to "DID NOT TOUCH THE DMA LAYER AT ALL," Torvalds writes (all-caps emphasis his), and was "literally just another user of it, in a completely separate subdirectory."
"Honestly, what you have been doing is basically saying 'as a DMA maintainer I control what the DMA code is used for.' And that is not how *any* of this works," Torvalds writes.
Torvalds writes Hellwig that "I respect you technically, and I like working with you," and that he likes when Hellwig "call[s] me out on my bullshit," as there "needs to be people who just stand up to me and tell me I'm full of shit." But, Torvalds writes, "Now I'm calling you out on *YOURS*."
The leader goes on to state that maintainers who want to be involved in Rust can be, and can influence what Rust bindings look like. Those who "are taking the 'I don't want to deal with Rust' option," Torvalds writes, can do so—later describing it as a "wall of protection"—but also have no say on Rust code that builds on their C interfaces.
"Put another way: the 'nobody is forced to deal with Rust' does not imply 'everybody is allowed to veto any Rust code.'" Maintainers might also find space in the middle, being aware of Rust bindings and working with Rust developers, but not actively involved, Torvalds writes.
“Why wouldn’t we do this?”
In an earlier response to the "Rust kernel policy" topic, Kroah-Hartman suggests that, "As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years … I think I can speak on this topic."
As the majority of bugs are due to "stupid little corner cases in C that are totally gone in Rust," Koah-Hartman is "wanting to see Rust get into the kernel," so focus can shift to more important bugs. While there are "30 million lines of C code that isn't going anywhere any year soon," new code and drivers written in Rust are "a win for all of us, why wouldn't we do this?" After casting doubt on C++ as a viable long-term codebase, Kroah-Hartman clarifies the obvious point that Rust, while not a "silver bullet," does a lot of things right, especially for developers trying to deal with the kernel's tricky APIs.
"Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible," Kroah-Hartman writes. "We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years."
Rust may or may not become an ascendant language in the kernel. But maintaining C as the dominant language, to the point of actively tamping down even non-direct interaction with any C code, did not seem like a viable long-term strategy. Many discussions on the topic have noted the existence of Redox, a Rust-centered microkernel, or the theoretical but technically possible forking of Linux into a C-only project. But they are both just a smidge dismissive of how important the active development of Linux, the dominant infrastructure OS, is to the world.
