Updated Some Linux kernel maintainers remain unconvinced that adding Rust code to the open source project is a good idea, but its VIPs are coming out in support of the language's integration.

In an ongoing thread on the Linux kernel mailing list, Greg Kroah-Hartman, a senior project developer, for one urged fellow contributors to embrace those interested in contributing Rust code to improve the kernel.

Adding another language shouldn't be a problem, we've handled much worse things in the past

"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," he [1]wrote on Wednesday.

"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-plus years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together."

[2]

His posts are the latest in a spat which [3]began last month when a proposed patch to allow Rust-written device drivers to call the primarily C-based kernel's core [4]DMA API was challenged by kernel maintainer Christoph Hellwig.

[5]

[6]

Hellwig likened maintaining a multi-language codebase [7]to cancer as he emphasized his disinterest in having to take on the burden of helping maintain Rust device driver code. The ensuing argument prompted Hector Martin, then project lead of Asahi Linux, to demand that Linus Torvalds decide whether the patch would be pulled into the kernel or not.

Torvalds eventually responded by defending the Linux kernel development process and [8]scolding Martin for grandstanding on social media about the issue. Martin later quit as a Linux maintainer and [9]resigned from the Asahi Linux project.

Policy pugilism

Miguel Ojeda, who contributes to the Rust for Linux project and to Linux kernel maintenance, [10]attempted to reassure the kernel development community by publishing a " [11]Rust kernel policy ."

Hellwig, who earlier this week [12]chimed in to reiterate his concerns about mixing Rust and C code in a single codebase, criticized Ojeda's Rust for Linux policy document on grounds it appeared on the web rather than in the kernel code tree.

[13]

He also expressed concern about the role of Rust in the kernel.

"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," he wrote.

[14]Type-safe C-killer Delphi hits 30, but a replacement has risen

[15]Time to make C the COBOL of this century

[16]Even Linus Torvalds can have trouble with autocycle … autocracy… AUTOCOMPLETE!

[17]'Maybe the problem is you' ... Linus Torvalds wades into Linux kernel Rust driver drama

In case you came in late, Rust was added to the Linux kernel in 2022 because it allows better memory safety than C.

Technical experts have for years pointed out that the majority of serious bugs and vulnerabilities in large codebases arise from memory safety errors, which could or should be avoided by using memory-safe languages and tooling. Boffins and governments thus argue that developers should use [18]memory-safe programming languages – eg, Rust, Go, C#, Java, Swift, Python, and JavaScript – whenever possible and as appropriate.

This is a prima facie sensible idea given the ubiquity of Linux.

The majority of bugs are due to the stupid little corner cases in C that are totally gone in Rust

Veteran C and C++ programmers, however, are understandably worried their skills could become less relevant. Many have therefore sought ways to achieve or approach memory safety without jumping on the Rust bandwagon.

Kroah-Hartman, [19]in response to Boqun Feng, a kernel developer with Microsoft, addressed the issue of Rust and memory safety directly.

[20]

"The majority of bugs (quantity, not quality and severity) we have are due to the stupid little corner cases in C that are totally gone in Rust," he wrote.

"Things like simple overwrites of memory (not that Rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the real bugs that happen (i.e. logic issues, race conditions, etc.)."

Kroah-Hartman goes on to say that he supports making C code more robust and that work won't stop, regardless.

"But for new code and drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this?" he wrote.

"C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time."

That comes with the usual caveats – as Kroah-Hartman acknowledged, Rust isn't a silver bullet that will magically solve all problems. But it will help, he insists.

Linus absolutely is going to merge Rust code over a maintainer's objection

It seems Kroah-Hartman is not alone in holding that view. Kees Cook, a kernel security engineer at Google and a long-time kernel contributor, for instance [21]said : "I don't see any reason to focus on replacing existing code – doing so would actually carry a lot of risk. But writing new stuff in Rust is very effective."

Among the issues raised about Ojeda's Rust kernel policy post, Hellwig corrected Ojeda's assertion that some kernel subsystem maintainers might decide they simply don't want Rust code and that that's to be expected and accepted.

"Linus in private said that he absolutely is going to merge Rust code over a maintainer's objection," Hellwig said. "So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not."

Count Torvalds in, too. ®

Updated to add

Torvalds has [22]politely responded to Hellwig's objections to Rust bindings being added to the kernel for the DMA API, correctly pointing out the proposed Rust code isn't even in the core C-based component that Hellwig maintains – the bindings act as a separate interface between the unchanged C API and Rust drivers.

Read the full email, but here are some excerpts...

The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. 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.

What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code?

That's literally exactly what you are trying to do with the Rust code.

So let me be very clear: if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG.

You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it. But "ignore the Rust side" automatically also means that you don't have any *say* on the Rust side.

"I respect you technically, and I like working with you," the kernel chief added.

Get our [23]Tech Resources



[1] https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z7gIe1pb01qdnHHrD3OK_wAAAdg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[3] https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/

[4] https://docs.kernel.org/core-api/dma-api-howto.html

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z7gIe1pb01qdnHHrD3OK_wAAAdg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z7gIe1pb01qdnHHrD3OK_wAAAdg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://lore.kernel.org/lkml/20250128092334.GA28548@lst.de/

[8] https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/

[9] https://www.theregister.com/2025/02/13/ashai_linux_head_quits/

[10] https://www.theregister.com/2025/02/11/rust_for_linux_project_support/

[11] https://rust-for-linux.com/rust-kernel-policy

[12] https://lore.kernel.org/rust-for-linux/Z7SwcnUzjZYfuJ4-@infradead.org/

[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z7gIe1pb01qdnHHrD3OK_wAAAdg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[14] https://www.theregister.com/2025/02/19/delphi_turns_30/

[15] https://www.theregister.com/2025/02/18/c_opinion/

[16] https://www.theregister.com/2025/02/18/linus_torvalds_autocomplete_mistake/

[17] https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/

[18] https://www.memorysafety.org/docs/memory-safety/

[19] https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/

[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z7gIe1pb01qdnHHrD3OK_wAAAdg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[21] https://lore.kernel.org/rust-for-linux/202502191026.8B6FD47A1@keescook/

[22] https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/

[23] https://whitepapers.theregister.com/