Lennart Poettering
d41bd96f54
This adds a minimal Varlink (https://varlink.org/) implementation to our tree. Given that we already have a JSON logic it's an easy thing to add. Why bother? We currently have major problems with IPC before dbus-daemon is up, and in all components that dbus-daemon itself makes use of (such as various NSS modules to resolve users as well as the journal which dbus-daemon logs to). Because of that we so far ended up creating various (usually crappy) work-arounds either coming up with secondary IPC systems or sharing data statelessly in /run or similar. Let's clean this up, and instead use a clean, well-defined, broker-less IPC for cases like that. This is a minimal implementation of Varlink, i.e. the most basic logic only. Stuff that's missing is left out on purpose: there's no introspection/validation and there's no name service. It might make sense to add that later, but for now let's only do the minimum buy-in we can get away with. In particular as I'd assume that at least initially we only use this IPC for our internal communication avoiding introspection and the name service should be fine. Specifically, I'd expect that we add IPC interfaces to the following concepts with this scheme: 1. nss-resolve (so that hostname lookups with resolved work before resolved is up) 2. journald (so that IPC calls to journald don't have to go through dbus-daemon thus creating a cyclic dependency between journald and dbus-daemon) 3. nss-systemd (so that dynamic user lookups via PID 1 work sanely even inside of dbus-daemon, because otherwise we'd want to use dbus to run dbus which causes deadlocks) 4. networkd (to make sure one can talk to it in the initrd already, long before dbus is around) And there might be other cases similar to this.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.