Committing to Rust in the Kernel
Linux kernel maintainers are cautiously experimenting with Rust as a second systems language, aiming to improve memory safety and long‑term maintainability without disrupting existing C code or development workflows. Commenters weigh potential gains—safer drivers, stronger type‑checked invariants, easier recruitment of new contributors—against practical and cultural hurdles such as unstable Rust features, limited compiler and platform support, unclear kernel API semantics, and resistance from C‑oriented veterans. Many see Rust’s growing use in areas like Android, Azure, and firmware as evidence it’s worth pursuing, but emphasize that kernel Rust must remain optional and not block core C‑side evolution.
Rust adoption beyond Linux (Microsoft, Azure, firmware)
- Commenters note active Rust use at Microsoft: parts of Win32k in Rust (
win32kbase_rs.sys), Azure Boost, para-virtualization (OpenHCL), Pluton firmware, and UEFI/Project Mu components. - Rust is described as the “official systems language” for new Azure infrastructure where GC’d languages are unsuitable.
Health and long‑term maintenance of Rust-for-Linux
- Some worry the Rust-for-Linux team is “falling apart” after a lead left; others counter this is exaggerated: it’s one person, work continues, and is funded (notably by Google).
- Skeptics point out Google’s history of killing products; defenders respond that Android’s heavy Rust usage makes long‑term abandonment unlikely.
C vs Rust and systems-programming philosophy
- Several threads compare “max-level C” (control via behavior and manual patterns) vs “max-level Rust” (control via types and lifetimes).
- Discussions cover arena allocators, ownership, reference counting, RAII, and whether “individual element” vs “group/arena” thinking is better.
- Some see Rust’s type-heavy approach as “authoritarian,” others see it as encoding the same constraints C programmers already follow informally.
Kernel APIs, invariants, and Rust abstractions
- Rust wrappers need precise semantics for C APIs (ownership, mutability, concurrency); many kernel APIs are under‑documented and behavior can be “it depends.”
- This creates friction when Rust devs ask for clarified semantics, especially around filesystems; some C maintainers resist having their informal contracts rigidly encoded.
- Ideas raised: quasi-stable, well-documented subsystem APIs vs “break what you want but fix all Rust call sites too.”
Toolchains, unstable features, and distro workflows
- Debate over depending on distro-packaged
rustcvs Rust’s own fast-moving release channel (rustup). - Distros value being able to rebuild the shipped kernel entirely from distro tools; developers often prefer upstream, current toolchains.
- Rust-for-Linux currently relies on a list of unstable features; many are claimed to be close to stabilization, but this forces tracking fairly recent nightlies and worries some about long‑term pinning.
Architecture support and scope in the kernel
- Rust (via LLVM) supports many but not all Linux architectures; several obscure ones are missing.
- Current policy: Rust is allowed only in drivers, which are inherently platform-specific, so unsupported architectures simply don’t get Rust drivers.
Motivations and evaluation of the Rust-in-kernel experiment
- Stated goals: alleviate maintainer shortages, improve memory and type safety, and modernize parts of the codebase without blocking C evolution.
- Rust code is explicitly experimental and may be broken by C-side changes; it must not impede core kernel work.
- Successes: example drivers, interest from downstreams (Android, ChromeOS). Struggles: tooling maturity, semantics clarification, social friction.
Correctness, compilers, and performance concerns
- Some worry Rust doesn’t map “1:1” to assembly and has only one mainstream compiler, invoking the “trusting trust” problem.
- Compiler engineers in the thread argue C also doesn’t map 1:1: both go through IR with optimizations and target-specific behavior; in practice,
unsafeRust is no worse than C here. - Others question whether encoding semantics in Rust’s type system is overreach; suggest thin
-sysbindings and moreunsafeuse instead of heavy wrappers. - Performance critiques: heavy generics/traits, atomics, and allocation patterns in common Rust libraries can hurt low-level performance; sometimes direct C APIs or
sysbindings perform better.
Media coverage and community dynamics
- Mixed views on LWN’s coverage: some see it as a trustworthy, coherent summary; others perceive bias toward Rust and note lack of prominent dissenting voices.
- There is visible tension between “embrace Rust” and “improve C tooling instead,” with some comments becoming heated, but also signs of willingness from some kernel maintainers to learn Rust given good documentation.