"... maybe the problem is you" - Linus

A long-running dispute inside the Linux kernel community over adding Rust centers on a single fault line: whether Rust can be integrated without turning core subsystems into a permanently cross-language maintenance burden. The flashpoint mail thread begins with pushback on Rust being used in DMA-related kernel code, with Christopher Helwig arguing that DMA interfaces should remain readable C and that duplicating Rust bindings across drivers would create a “bike-shedding” maintenance nightmare—especially for developers who navigate code with tools like grep rather than modern language servers.

Danilo (spelled “Danilo” in the transcript) counters with a more structured proposal: Rust drivers should not call C DMA APIs directly. Instead, Rust should provide a maintained abstraction layer that wraps the C DMA API once, so each Rust driver consumes the same Rust-side interface rather than re-implementing glue code. The goal is to keep the Rust layer as a single “midlayer consumer” of the DMA API, reducing duplicated code and limiting where breakage would occur when the underlying C interfaces evolve. In this framing, the Rust abstraction would be maintained by Rust maintainers, and changes to the C API would be handled through coordinated updates—similar to how kernel components already collaborate when C-side APIs shift.

Christopher Helwig’s opposition sharpens around maintainability and boundaries. He argues that adding another language consumer increases the maintenance surface area of the kernel as an integrated project, warning that even if Rust maintainers promise to keep up, the practical reality is that Rust becomes downstream of C changes. That downstream position can mean constant “fast-follower” work whenever C APIs change, and it also raises concerns about what happens if Rust maintainers leave or can’t respond quickly enough.

The thread then escalates from technical process to governance expectations. A key exchange references Linus Torvalds’ enforcement stance: Rust-related build failures must be handled in the normal development workflow, and the responsibility for keeping Rust builds working is treated as a shared obligation depending on whether changes are in staging or core paths. Greg Kroah-Hartman weighs in by distinguishing between tooling/build breakage and true API-change breakage, and by emphasizing that when core subsystem changes land and break Rust builds, the Rust maintainers are expected to fix the Rust side as part of the normal kernel integration process.

Beyond the Rust-vs-C technical debate, the transcript also captures a parallel conflict over tone and community norms. A “cancer” remark aimed at another contributor triggers discussion of code-of-conduct boundaries and social-media “brigading,” with Linus Torvalds pushing back on inflammatory language and urging participants to keep arguments technical and process-focused. The thread ultimately lands on a pragmatic compromise: Rust can be integrated, but the community wants clear expectations about where breakage is allowed, who fixes it, and how to avoid multiplying maintainers and duplicated abstractions across drivers.

Overall, the core finding is that Rust integration is less about whether Rust is “better” and more about whether the kernel can absorb cross-language complexity without creating a permanent downstream maintenance tax—an issue that, in practice, depends on coordination speed, maintainer continuity, and explicit rules for when Rust builds must pass versus when staging breakage is acceptable.