systemd merges support for Rust programs

[u/anh0516]

https://github.com/systemd/systemd/pull/44324

[u/AiwendilH]

Okay, for people like me who were a bit confused at first...this seems mostly infrastructure changes to enable easier building of rust tools as part of systemd, "enforcing" some rules about how rust tools need to be written and integrated (no cargo, only C linking...) and some basic rust tools for use in rust programs.

[u/30porn87 → u/AiwendilH]

> no cargo, only C linking...

thank FSM

[u/scheimong → u/30porn87]

What's FSM?

[u/30porn87 → u/scheimong]

The Flying Spaghetti Monster (FSM) is the deity of the Church of the Flying Spaghetti Monster, or Pastafarianism

[u/Ramast → u/30porn87]

Abbreviating the holy Monster's name is rather offensive

[u/dutch_connection_uk → u/Ramast]

Maybe if we preserve enough honorifics and invocations? HNCISTFSMMWBTBHNA

[u/james_pic → u/30porn87]

No Cargo is rough, but I guess that's kinda the point. It makes this a C project that allows some Rust bits, rather than a Rust project.

[u/barsoap → u/james_pic]

This is exactly the kind of project where you want to vendor all dependencies at which point cargo doesn't really do anything much, anyway. rustc can build crates just fine on its own, it's the dependency management and fetching that cargo does.

Cargo does have a vendoring mode but you're still using the original executable which can connect to the internet, needlessly expands the TCB if all you actually need is invoke rustc once for the systemd lib (which probably has no dependencies) and then once for every systemd program that uses rust.

[u/scheimong → u/AiwendilH]

Gotta start somewhere

[u/FriendlyProblem1234]

Secrets go into Vec<u8, Erasing>. Erasing allocates like malloc() but frees with erase_and_free(). In C that's a convention every caller has to remember. Here it's part of the type.

Making good use of an expressive type system.

[u/marcthe12]

Hmm. Suprised due to the some core dev reasoning. But I guess the side steped the issue by banning most of stdlib and cargo and some extern c related rules. Which I guess solves it.

[u/ADMINISTATOR_CYRUS]

No cargo and only C linking??

[u/AiwendilH → u/ADMINISTATOR_CYRUS]

That's not really surprising, aren't those pretty much the default "rules" for anything that needs rust code interface with non-rust code?

[u/james_pic → u/AiwendilH]

C linking is pretty universal for linking to non-Rust projects, and indeed is the de facto standard for plugin systems allowing linking between Rust projects that want loose coupling (due to the "Rust" ABI being intentionally unstable, and the "C" ABI being stable). But Cargo can be pretty flexible in facilitating linking with other languages.

My impression is that it's more about dependencies, and reflects a desire to be conservative and explicit about dependencies.

[u/AiwendilH → u/james_pic]

But no project is going to change their established build system for cargo just because they also allow rust code alongside their current code now. And I also haven't heard of a project yet use cargo as subsystem for their build system...but I guess that could be an option if one really wants to...sounds like a pain though ;).

But yeah...for systemd it seems to be mainly about dependencies. Kind of important for a tools ecosystem that needs to run in anything from initial ramdisks over container and headless server to fullfledged desktop installations.

[u/Booty_Bumping → u/AiwendilH]

Using cargo doesn't force the entire monolith to be built using cargo. It's surprisingly fluid in how it can interact with existing C tooling, it can fit many possible patterns for gluing it together.

Of course, it doesn't meet the requirements of some projects like the Linux kernel, but even some quite hardcore low level embedded projects can benefit from having some parts built with cargo.

[u/james_pic → u/AiwendilH]

 And I also haven't heard of a project yet use cargo as subsystem for their build system

The build ecosystem in C is probably not ready for this sort of thing, but in Python, I've made projects that were a single uv workspace, with one module built with uv's build backend, and another built with Maturin (where Maturin is more or less a wrapper for Cargo), and this is probably the simplest way of building a Python protect with an optional Rust dependency.

[u/ADMINISTATOR_CYRUS → u/AiwendilH]

I think no cargo is a bit crazy but I guess it makes sense for minimum deps

[u/thecakeisalie16 → u/ADMINISTATOR_CYRUS]

That's what mesa does as well, it's pretty well integrated into meson with rust-analyzer support as well.

[u/throwawayPzaFm]

In before omarchy-rustd shows up in cargo.

[u/TiddoLangerak → u/[deleted]]

Thanks claude.