EEE

The systemd project has officially introduced support for developing programs in Rust, following the merger of a pull request submitted by Linux kernel developer Christian Brauner. The change, merged into the project’s main branch, establishes a new development option for systemd while keeping its existing C-based architecture intact.

And before anyone assumes systemd is preparing a complete rewrite in Rust, that’s not the case. The maintainers agreed on a deliberately limited approach: Rust may be used only for new, standalone components that other parts of systemd do not depend on. Existing C code will remain untouched.

Another important decision concerns the build process. Rather than introducing Cargo, Rust’s standard package manager and build tool, systemd continues to use Meson for all builds. This keeps Rust development integrated into the project’s existing build infrastructure.

The implementation also places strict limits on dependencies. Rust programs use the no_std approach, meaning they do not rely on Rust’s standard library or external third-party crates. Instead, they interact with systemd’s existing C libraries through generated bindings.

For memory management, systemd provides its own Rust implementations of common container types, with allocation failures handled explicitly rather than causing the program to abort. The new infrastructure also includes wrappers for logging, command-line argument handling, event processing, and error management, allowing Rust utilities to behave consistently with their C counterparts.

Rust support is optional and automatically detected during configuration. Developers wishing to enable it need Rust 1.85 or later, bindgen 0.71.1 or later, and Meson 1.4 or later. Systems without the required toolchain can continue building systemd without Rust support.

Interestingly, initial tests show that a stripped Rust command-line utility occupies about 32 KB, compared to 20 KB for its C equivalent built with link-time optimization. This gives an early indication of the additional overhead, though the comparison involves only a small test program.

The first planned real-world application of this infrastructure is systemd-keyring-setup, a new utility intended to help manage certificates in Linux kernel keyrings. Its implementation is being developed separately, alongside additional Rust wrappers for systemd’s shared libraries.

For Linux distributions, the change introduces packaging considerations. Builds that enable all available features will need the appropriate Rust compiler and bindgen dependencies or must disable Rust support to avoid build failures.

Whether Rust becomes widely used within systemd will depend on future development, but the necessary groundwork is now in place.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 6 hours ago (4 children)

Personally, I don’t really see the point, because there’s hardly any projects that can be compiled with just rustc.

Because having rustc as a standard tool is not there yet. Off course most don't expect someone to have rustc only on their computer. I love Cargo, don't get me wrong. But I think there could be a rise of non Cargo and library dependency projects in future, if the infrastructure (meaning rustc and the standard library can be expected as standard dependency) is available once.

Just like not every little project of C requires additional dependency trackers. One could download a project from Git and build it with rustc+make and only the dependencies available in your repository. One of the major issues with the public cratesio is, that not everyone wants to depend on it. In example Linux or other projects don't use it (as far as I know). So there might be use cases. Just like we use Python and Haskell without additional libraries, or only install them from our systems repository.

Maybe it shouldn't be installed by default. But having an infastructure with basic system packages to install only "Rust" (rustc+stdlib), no cargo, no rustfmt, no rustup. Maybe this will be available once gcc-rust is ready.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 0 points 5 hours ago (3 children)

    I think you're clearly clueless and should stop opining on matters you know nothing about.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 5 hours ago (2 children)

    I think you don't know what you are talking about.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 0 points 4 hours ago* (1 child)
    • You're clueless about how cargo itself wraps/calls rustc. And how other build systems are doing the same, including the one literally mentioned in OP. "Because having rustc as a standard tool is not there yet" is a completely meaningless nonsensical sentence. Neither is rustc lacking in any way, nor is cargo imposes any sort of hard requirement on itself.
    • You're clueless about how cargo works. How it natively supports both vendoring (with a single command) and multiple other ways of source replacement.
    • You're clueless about the fact that rust statically links std by default, and the fact that the ABI is not stable between major rust versions which is a deliberate choice. And thus, the attempt to draw parallels with "C repo and make" is yet another indicator of your cluelessness.

    There is more. But I don't have the time untangle the webs of cluelessness in your comments.

  • source
  • parent
  • hideshow 1 child comment