Rust in the Linux Kernel: How Far Has Adoption Actually Gone?
A status check on Rust in the Linux kernel: lines of code, which subsystems use it, platform support gaps, and what maintainers actually say.
What is the current state of Rust in the Linux kernel?
Rust in the Linux kernel is still small but growing fast. As of kernel 7.2.4, there are roughly 473 Rust source files, about 114,000 lines of Rust code, and six driver subsystems using it, which works out to around 0.38% of the kernel by volume. That is a tiny slice of a codebase with millions of lines of C, but the trajectory matters more than the snapshot: Rust support has expanded steadily since it was first merged, and the pace has picked up in recent releases. No Rust code currently lives in the kernel’s core critical paths. It is concentrated in drivers and subsystem-level abstractions instead.
TL;DR
- Rust support was proposed in 2021 and merged in minimal form in 2022, starting as a bare framework rather than a wholesale rewrite of anything.
- Adoption is uneven across subsystems: DRM/GPU leads with the most Rust code of any area, while other subsystems have Rust abstractions merged but nothing yet using them.
- Real Rust drivers already ship, including networking drivers for the AX88772A and a generic Realtek chipset, plus PWM abstractions and Android components like Binder.
- Greg Kroah-Hartman has publicly argued that Rust would have prevented a large share of the CVEs he’s reviewed over 25 years, framing the language choice around reviewer bandwidth rather than developer preference.
- Platform support gaps are more about kernel tooling than the Rust language itself, and architectures like PowerPC have recently moved from experimental to maintained Rust support.
- No Rust exists in the kernel’s core critical code paths yet, and any move in that direction will be gradual because of testing and platform-support requirements.
- The DRM/GPU subsystem has floated eventually rejecting new C drivers entirely, keeping old ones on life support while requiring new work to be written in Rust.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
How did Rust get into the kernel in the first place?
Rust support was first proposed in 2021, building on earlier exploratory work, and the initial merge landed a year later in 2022. That first merge wasn’t a driver or a subsystem. It was minimal scaffolding meant to prove the language could coexist with the rest of the kernel at all. Introducing a new language into a project with this many lines of code and this many downstream users is inherently risky, so the approach was deliberately incremental: get the basic plumbing in, then build outward only once each layer is solid.
Early proposals ran into real friction. One widely cited episode involved Linus Torvalds objecting to how the initial Rust support handled out-of-memory conditions. A userspace application can panic and exit if memory runs out. A kernel can’t just do that, because a panic there can take the whole system down. That kind of mismatch between “how Rust programs normally behave” and “how the kernel has to behave” needed to be resolved before Rust could be trusted with anything meaningful, and much of the tooling built since has been about closing those gaps.
Why do some maintainers want Rust in the kernel?
The clearest public case comes from Greg Kroah-Hartman, who has said Rust “makes coding fun again” and estimated, admittedly unscientifically, that around 80% of the CVEs filed against the kernel over the past 25 years would have been caught by Rust’s compiler before the code ever shipped. His argument isn’t really about developer happiness, though. It’s about reviewer load. Linux has thousands of contributors but only around 150 core maintainers who review the bulk of incoming code. Kroah-Hartman has framed the entire push around that imbalance: “We optimize for reviewers. We don’t optimize for developers because we have a lot of developers.”
The logic is that if a Rust patch compiles, a reviewer can trust that whole categories of bugs (memory safety issues, certain locking mistakes, lifetime errors) simply aren’t present, freeing them to focus on whether the logic is actually correct. C offers no such guarantee at compile time. Rust doesn’t eliminate bugs entirely; Kroah-Hartman has been explicit that Rust code can still crash and still contains logic errors. But it removes an entire class of “dumb, weird little issues” that C lets slip through, according to his framing.
Which parts of the kernel actually use Rust today?
Adoption is patchy by design, since the kernel functions less like one unified project and more like a federation of subsystems with shared governance and different local rules.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
DRM and GPU are the clear front-runners. This subsystem has the most Rust code in the kernel, including the Nova driver for NVIDIA hardware and the Tyr driver for Arm Mali GPUs, alongside supporting tooling. Some maintainers in this space have floated a future where new GPU drivers must be written in Rust, with existing C drivers kept around and maintained but not treated as a template going forward. It’s not certain that policy will actually hold, but it reflects where sentiment currently sits among the people working on it.
Beyond graphics, adoption looks like this:
- Android subsystems use Rust in components like Binder.
- Networking has real Rust drivers in the tree, including support for the AX88772A and a generic Realtek driver.
- PWM has Rust abstractions along with at least one driver.
- Several other subsystems, including filesystem code, have Rust abstractions merged or close to merged, but nothing yet actually consumes them. The scaffolding exists; nothing calls it yet.
Outside the mainline tree, related work is progressing too. There’s ongoing NVMe driver work in Rust, and Asahi Linux has been upstreaming pieces of scaffolding for a Rust-based GPU driver, though the driver itself remains in progress.
Is platform support a real barrier for kernel Rust?
Partially, but the common framing overstates the problem. Rust as a language already has broad platform support for writing ordinary applications; that’s not where the gap is. The actual gap is in kernel-specific tooling: the scaffolding needed to build and integrate Rust code for every architecture the kernel supports. That tooling doesn’t yet cover every architecture Rust itself supports, or even every architecture the kernel supports.
This is improving. PowerPC support recently moved from experimental to maintained status, opening that architecture up for further Rust experimentation. But there’s a real possibility that some of the kernel’s more obscure, lightly used architectures eventually get dropped partly because maintaining Rust tooling for them isn’t worth the effort relative to how few people rely on them. That would follow a pattern the kernel has used before with old hardware support, just at a higher frequency than in the past.
What comes next for Rust adoption?
No Rust code currently exists in the kernel’s core critical paths, and that’s likely to remain true for a while. Touching core kernel internals with Rust risks breaking platforms that lack full Rust tooling, and any change there requires far more testing than a driver update. The realistic path forward is incremental: subsystems that already have Rust abstractions slowly start actually using them, more drivers get rewritten (not just newly written) in Rust, and platform tooling keeps catching up architecture by architecture.
It’s also worth remembering Rust isn’t the kernel’s first attempt at a second language. C++ was proposed and firmly rejected by Torvalds long before Rust came along, for reasons that mostly no longer apply to the language today. That history makes Rust’s success notable: it got further than any prior alternative, and current subsystem interest suggests the amount of Rust code in the kernel is going to keep climbing, even if the overall percentage stays modest for years.
Frequently Asked Questions
How much of the Linux kernel is written in Rust?
As of kernel version 7.2.4, Rust accounts for about 114,000 lines of code across roughly 473 files, spread over six driver subsystems. That’s about 0.38% of the kernel overall, though the amount has been increasing with recent releases.
Which Linux kernel subsystem has the most Rust code?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
DRM and GPU. It hosts drivers like Nova (for NVIDIA hardware) and Tyr (for Arm Mali GPUs), along with supporting infrastructure, and some contributors in that space have discussed eventually requiring new drivers to be written in Rust rather than C.
Does Rust support work on all CPU architectures the kernel supports?
Not yet. The Rust language itself has wide platform support, but the kernel-specific tooling needed to integrate Rust for every architecture is still incomplete. Support is improving gradually; PowerPC, for example, recently moved from experimental to maintained status for Rust use.
Is Rust used in the core parts of the Linux kernel?
No. As of now, Rust is confined to drivers and subsystem-level code, not the kernel’s core critical paths. Any expansion into core code will likely be slow and heavily tested given the platform-support gaps that still exist.
Why do some Linux maintainers support adding Rust?
The main argument, publicly made by Greg Kroah-Hartman, centers on reviewer workload rather than developer preference. With only around 150 core maintainers reviewing code from thousands of contributors, Rust’s compile-time guarantees around memory safety and locking let reviewers focus on logic errors instead of catching low-level mistakes by hand.