The Linux Kernel Prepares for Rust 1.77 Upgrade

Original Article ↗ Hacker News Discussion ↗

Linux’s move to newer Rust toolchains, including the planned upgrade to Rust 1.77, is prompting debate over how much the kernel should rely on unstable compiler features and what that means for long‑term maintainability. Commenters weigh Rust’s benefits—memory safety, modern abstractions, and evolving allocator support—against practical concerns such as compiler bootstrapping, binary size, and the still‑tiny proportion of kernel code written in Rust. There is broad agreement that Rust will remain optional and incremental in the kernel for now, serving as a testbed to shape both the language and its tooling for low‑level systems work.

Rust versioning and kernel use of unstable features

  • For ordinary projects using stable Rust, compiler upgrades are mostly backward compatible; tools like clippy and cargo fmt help track style and lint changes.
  • Rust-for-Linux deliberately uses nightly/unstable features, so upgrades can require non-trivial fixes.
  • This is seen as necessary to exercise missing features (e.g., offset_of, allocator APIs) and help push them toward stabilization.
  • Estimate cited: ~0.5 hours per million lines of Rust to upgrade compilers in large codebases; Rust-for-Linux has higher overhead due to nightly use.

Allocators and memory handling

  • Kernel needs fine-grained, fallible, and per-object-type allocation, pushing it toward unstable Allocator APIs instead of just GlobalAlloc.
  • allocator_api provides fallible construction (e.g., try_new) and flexibility that stable APIs lack.
  • Standard library alone is allowed to use unstable features; third-party crates cannot on stable.

Binary size and dependencies

  • Many Rust binary-size complaints are tied to:
    • Debug/panic machinery (e.g., backtrace, Unicode-aware formatting).
    • Static linking of std.
    • Heavy dependency trees and monomorphization.
  • In no-std contexts (microcontrollers, kernel) binaries can be much smaller.
  • Strip/debug-splitting and upcoming Cargo defaults will reduce sizes; but Rust “hello world” still has a relatively large constant overhead vs C.
  • Some argue large build trees and caches (hundreds of MB) are problematic; others note this is comparable to modern toolchains and that in-kernel Rust won’t pull in big dependency graphs.

Extent and structure of Rust in the kernel

  • Rust code is currently a tiny fraction of the kernel (on the order of ~0.03–0.05% of lines).
  • Most is infrastructure; Rust drivers are still “rounding errors,” with examples like an Android binder rewrite.
  • Kernel uses core and a custom alloc, but not std.

Bootstrapping, LFS, and toolchains

  • Concern: Rust’s bootstrapping story is “ugly” and might threaten Linux From Scratch (LFS).
  • Counterpoint: LFS already assumes a host C compiler; similarly it could assume a host Rust compiler and only use rustc to produce object files.
  • Compared to bootstrapping other complex compilers (e.g., GHC), Rust’s situation is criticized but not unique.

Low-level safety, pointers, and language choice

  • Discussion of unsafe pointer operations and macros vs safe pointer arithmetic highlights subtle UB and performance trade-offs.
  • Clarification of Rust’s library layers: core (language primitives), alloc (heap types), std (OS-dependent features).
  • Some want not just a language rewrite but formal verification akin to seL4.
  • Question raised: “Why Rust instead of Zig?”
    • One side values Rust’s strong memory-safety guarantees.
    • Another claims memory bugs can be handled with tests and that Rust’s safety has its own trade-offs; no consensus reached.