systemd 263 merges Rust support for new leaf components via Meson build
systemd 263 will allow new leaf modules to be written in Rust, but only without Cargo, without the Rust standard library, and without touching existing C code or core dependencies.
Summary
Developer Christian Brauner announced that Rust support has been merged for the upcoming systemd 263 release, following the systemd 262 release approximately one month prior. The implementation arrives through five split pull requests, with the most prominent enabling Rust-written support programs as new leaf components rather than rewrites of existing C code. The change imposes strict constraints: no Cargo for builds, no Rust standard library usage, and no conversion of existing code or core dependencies.
The build system relies entirely on Meson, which systemd already uses, alongside bindgen for C header bindings. The requirements specify Rust 1.85 or later, bindgen 0.71.1 or newer, and Meson 1.4.0 or above. Brauner noted that deeper Rust integration into systemd's core is currently blocked by limitations in Rust's dynamic library support. This marks a measured, incremental adoption rather than any broader Rust rewrite initiative.
How Rust fits into systemd's build and architecture
- Leaf-only restriction: Rust is permitted solely for new leaf components; existing C code will not be ported, and no Rust modules may become dependencies for other systemd components.
- Meson-only builds: All Rust compilation flows through Meson with Ninja; Cargo is explicitly excluded, requiring manual dependency management and binding generation.
- No standard library: Rust code must use no_std environments, typical of embedded Rust but unusual for systems software, demanding direct libc or kernel syscall usage.
- Toolchain requirements: Rust 1.85 (February 2025), bindgen 0.71.1 (December 2024), and Meson 1.4.0 (March 2024) form the minimum supported toolchain, all versions already available in current distributions including Debian 13.
- Dynamic library blocker: The systemd team indicated interest in deeper Rust integration but cited Rust's presently insufficient dynamic library support as preventing core subsystem adoption.
Why it matters
For Linux distribution maintainers, this change adds Rust to systemd's build-time dependencies without disrupting existing packaging workflows, since required toolchain versions are already widely available. The no_std and no-Cargo constraints mean Rust modules will operate closer to C in terms of system interaction, potentially appealing to kernel-adjacent and embedded developers but creating friction for typical application Rust programmers accustomed to the standard library and crates.io ecosystem. The decision to avoid rewriting existing C code preserves systemd's proven stability while opening a path for memory-safe new components, aligning with broader industry interest in Rust for systems software without the disruption of a ground-up rewrite.
Original reference: www.theregister.com →