Rust kernel policy

Governance and Policy Clarity

• Several commenters feel the Rust-for-Linux effort lacks a clear, enforced policy: who decides what, what maintainers must accept, and how cross-language interfaces should work.
• Some argue Linux’s distributed governance (subsystem maintainers with a lot of autonomy) makes it hard to impose a coherent Rust strategy without stronger direction from the top.
• Others counter that Linus’s approach—allow Rust, but let subsystem maintainers decide—is appropriate given project size and complexity.

Linus’s Role and Maintainer Conflicts

• Strong criticism that the current “political mess” is largely due to Linus approving Rust without clearly defining what that means in practice.
• One side wants him to either explicitly back Rust (and overrule blocking maintainers) or clearly say “no Rust” to avoid wasting effort.
• Others reply that he must trust maintainers, can’t centrally micromanage every subsystem, and that some behind-the-scenes coordination is already happening.

Technical and Toolchain Issues

• Concerns about mixing GCC (for C) and LLVM/Clang (for Rust and bindgen) in kernel builds; some kernel developers historically oppose mixed toolchains.
• Rust’s use of unstable language features is seen as a risk; defenders note that:
  • Kernel has long depended on non-standard GCC extensions.
  • Rust and kernel teams coordinate to stabilize what the kernel needs.
• Questions around static linking of libgcc and long-term compatibility of Rust-generated code.

Rust vs. C: Safety, Complexity, and Culture

• Pro-Rust arguments:
  • Memory safety is increasingly mandated (governments, industry); Linux must compete.
  • Rust is easier to write correctly than C; C is “simple to learn, hard to use safely.”
  • Rust is particularly valuable for drivers and DMA-safe abstractions.
• Skeptical views:
  • Rust feels complex/“PhD-level” to some; fear existing C maintainers won’t adopt it.
  • Cross-language codebases and bindings are called “cancerous” or maintenance nightmares.
  • One commenter argues Linux’s unstable APIs, monolithic design, and GCC focus make deep Rust integration fundamentally mismatched; a full Rust OS (e.g., Redox) is seen as cleaner.

Project Identity and Support

• Confusion over who “we” is in the Rust-kernel policy; some want clearer attribution and authority.
• Clarified in-thread: Rust-for-Linux is led by kernel folks, not the Rust Foundation, but the Rust project treats “R4L on stable Rust” as a flagship goal and actively supports needed language work.
• There is debate over naming individuals publicly due to concerns about harassment and misplaced responsibility.

Long-Term Outlook

• Some predict old-guard C maintainers may eventually leave as Rust use grows and new generations of developers arrive.
• Others think Rust will remain limited to drivers and select subsystems, never supplanting C wholesale.
• Overall, commenters see high technical promise but unresolved governance, social, and tooling tensions.