The Rust-For-Linux Pull Just Got Interesting
I use Arch, btw — and on my system the kernel is built with Clang precisely because of small wins like this one. Miguel Ojeda's Rust-for-Linux pull request for the Linux 7.1 merge window landed this month, and buried in the changelog is a new Kconfig option that does something the C side has been doing for years: it inlines tiny helper functions across the language boundary. The option is `CONFIG_RUST_INLINE_HELPERS`, it's experimental, and it gives you a measurable speedup for free if your toolchain is set up correctly.
This is the kind of plumbing improvement that doesn't make the front page of LWN, but it matters. Rust-in-the-kernel has been carrying a small but real performance tax compared to equivalent C, mostly because every call from Rust into a C `static inline` helper turned into an actual function call instead of getting inlined like it would in a pure C build. 7.1 starts closing that gap.
What CONFIG_RUST_INLINE_HELPERS Actually Does
The Linux kernel is full of `static inline` C helpers — wrappers around `READ_ONCE`, atomic ops, refcounts, list manipulation, the works. When pure C calls these, the compiler inlines them and you get zero function-call overhead. When Rust calls them, historically you got a real `call` instruction every single time, because the C helper lived in a separate translation unit and the linker doesn't normally see across that boundary.
The new option fixes that the same way LTO does — except scoped narrowly to just the C helpers Rust talks to. The build system emits LLVM IR for the C helper translation units, the Rust frontend emits LLVM IR for the Rust side, and `llvm-link` stitches them together before object code generation. Once the IR is unified, the inliner can do its job across what used to be an opaque ABI boundary.
The early result: the Rust null block driver — `null_blk` reimplemented in Rust, used as a benchmark target precisely because it stresses the kernel-Rust call path — runs roughly 2% faster with the option enabled. Two percent doesn't sound dramatic, but for a hot-path block driver on synthetic workloads, every percentage point comes from somewhere real, and this one comes from eliminating call overhead that shouldn't have been there in the first place.
The Clang Requirement
Here's the catch, and it's a meaningful one: this only works if your kernel's C compiler is LLVM Clang, not GCC. And not just any Clang — the LLVM major version of Clang has to match the major version of LLVM your `rustc` was built against. If you're on rustc 1.85, that's LLVM 19, so you need Clang 19 to do the C side too.
This is a hard requirement, not a preference. The whole trick depends on producing compatible LLVM IR from both compilers, then linking it. Mismatched major versions produce IR the other end can't consume.
For distros, this splits the world. Arch builds its kernel with GCC by default, so `linux` and `linux-zen` won't get this for free — you'd want `linux-llvm` or a custom build. Fedora and openSUSE have been moving toward Clang-built kernels for some workloads. Debian and Ubuntu? GCC, GCC, GCC. ChromeOS and Android, on the other hand, already build with Clang exclusively, so they're going to pick this up by default the moment they pull a 7.1-based kernel.
Is the year of the Linux desktop already happened? Sure. Is the year of the Clang-built distro kernel here yet? Not quite — but pulls like this one keep nudging the needle.
Toolchain Bumps: Rust 1.85, Bindgen 0.71.1
The other big change in this pull is the minimum-supported-toolchain bump. Rust-for-Linux on 7.1 requires:
- **Rust 1.85** (up from 1.78 on prior kernels) — that's a 7-version jump, which lets the kernel drop a pile of `#![feature(...)]` workarounds and use language features that have stabilized in the meantime. - **Bindgen 0.71.1** (up from 0.65.1) — needed for FFI generation against modern kernel headers.
This matters because Rust-for-Linux has historically pinned to whatever Rust version was current when a given LTS was cut, which made it painful for distributions stuck on older toolchains. Pushing the floor up to 1.85 is a signal that the project is past its bootstrap phase and willing to demand a recent toolchain. Good. The whole point of moving to Rust was to get the language's safety guarantees, and you don't get those by pinning to a three-year-old compiler forever.
The 1.78 → 1.85 jump in particular pulls in stable `RFC 3373` improvements, several `const fn` expansions, and a chunk of trait-related fixes that Rust-for-Linux had been carrying as feature gates. Less unsafe-feeling code, fewer `#![feature]` lines at the top of kernel modules.
What's Next On The Rust-For-Linux Roadmap
The inline-helpers work is a tactical win, but the strategic roadmap is bigger. The Rust project's official 2026 goals for Rust-for-Linux include stabilizing `arbitrary_self_types` (custom smart pointers as method receivers — critical for kernel ref-counting types), `build-std` (rebuilding `core`/`alloc` for custom targets, which the kernel needs because it can't use the standard `std`), ADT const parameters, and a const-traits MVP.
Each of those is currently a `#![feature]` declaration in mainline kernel Rust code. Each one stabilizing means one less pin to a nightly-adjacent toolchain. The endgame is exactly what the Rust Project Goals doc states: build the kernel with stable Rust, no feature gates, on all the targets the kernel supports. We're not there yet, but 7.1 chips off another piece.
The Bigger Picture
If you've been watching Rust-for-Linux from the sidelines, the 7.0 release earlier this month was the symbolic moment — Rust crossed from "experimental opt-in" to "integral part of the kernel." 7.1 is the unsexy follow-up where the engineering work of making it actually fast starts in earnest. Inline helpers today, full LTO across the C/Rust boundary tomorrow, and eventually the kind of cross-language whole-program optimization that erases the runtime cost of mixing the two.
The first 7.1-rc lands April 26th. If you're running a Clang-built kernel, watch for `CONFIG_RUST_INLINE_HELPERS=y` showing up in the next round of distro kernels. If you're on GCC — well, maybe it's time to try `linux-llvm`. I use Arch, btw.
Loading comments...