Rust for Filesystems

Original Article ↗ Hacker News Discussion ↗

Linux kernel developers are weighing the benefits and costs of using Rust for filesystem code, especially in the Virtual Filesystem (VFS) layer. Supporters argue that Rust’s type system and safety guarantees can encode complex lifecycle and concurrency invariants that are currently informal in C, potentially reducing bugs and making drivers easier to write, while critics worry about added complexity, long‑term maintenance of parallel C/Rust APIs, and dependence on unsafe blocks for low‑level operations. The exchange highlights broader questions about how far to push safety abstractions in a mature C codebase and whether Rust should mirror existing C interfaces or introduce stricter, more expressive ones.

Rust in the kernel: complexity tax vs payoff

  • Some see Rust support as an extra “complexity tax” on an already huge C codebase, especially for subsystems like filesystems, not just leaf drivers.
  • Others argue that any new subsystem adds complexity, but Rust can reduce net complexity by making drivers easier and safer to write, especially when many drivers can share better abstractions.
  • Concern: when Rust stops being fashionable, the kernel could be left with two partially maintained language islands. Counterpoint: no one understands the entire C kernel either; every subsystem already has its own learning curve.

“Safe subset of C” vs Rust’s safety model

  • Several commenters reject the idea of a truly “safe subset of C”; undefined behavior and integer quirks are deeply embedded in C.
  • Tools and standards (MISRA, Frama‑C, formal proofs like seL4) help, but they are external to the language, not guaranteed by it.
  • Rust’s model is praised for encoding invariants in the type system, especially object lifecycles and concurrency properties.

Unsafe Rust: blast radius and debugging

  • Agreement that one bad unsafe block can corrupt everything, just like C UB.
  • The value is not limiting damage but drastically shrinking and localizing the code that needs deep audit; unsafe sites are easy to grep and review.
  • Some note that logic errors in safe code can still violate assumptions of unsafe code; discipline and design still matter.

Async and concurrency in Rust

  • Rust’s thread‑safety traits (Send, Sync) are seen as a major win for concurrent code.
  • Rust async is widely described as rough and invasive compared to C#/Python/JS; runtimes and lifetimes add complexity even if syntax looks similar.

Filesystems, VFS semantics, and Rust APIs

  • Big tension: Rust developers want to encode filesystem object lifecycles (e.g., inodes) into types, while C-side devs worry this will freeze or complicate evolution of VFS semantics.
  • There is confusion about how different filesystems can share lifecycle functions but rely on divergent semantics; some see this as evidence the C APIs are under‑specified and ripe for refactoring.
  • Name divergence between C and Rust APIs is debated: clearer, more semantic Rust names help safety, but make cross‑referencing harder.

C interop and bindings

  • Multiple comments stress that calling C from Rust is straightforward via extern "C" and tools like bindgen; complexity arises with large, macro-heavy APIs, as in other languages.
  • Some argue the real issue is not low-level FFI, but how far to go in building higher-level, semantic Rust wrappers over evolving C APIs.

Community, civility, and politics

  • Several note the kernel Rust discussion itself is unusually civil given the stakes; many see this as a healthy, iterative process where “no” is expected and informative.
  • A side thread debates an Asahi Linux referrer banner criticizing HN moderation and online harassment.
    • One side views it as calling attention to serious abuse and the impossibility of being “apolitical.”
    • Others see it as irrelevant “politics,” an overreach into speech/freedom, or ineffective posturing toward users who cannot change HN policy.