Committing to Rust in the Kernel
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.