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 rustc vs 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, unsafe Rust is no worse than C here.
  • Others question whether encoding semantics in Rust’s type system is overreach; suggest thin -sys bindings and more unsafe use 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 sys bindings 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.