Lennart Poettering
8531631763
So far, if we do a synchronous varlink call from the client side via varlink_call(), we'll move the returned json object from "v->current" into "v->reply", and keep it referenced there until the next call. We then return a pointer to it. This ensures that the json object remains valid between two varlink_call() invocations. But the thing is, we don't need a separate field for that, we can just leave the data in "v->current". This means VARLINK_IDLE_CLIENT state will be permitted with and without v->current initialized. Initially, after connection setup it will be set to NULL, but after the first varlink_call() it will be set to the most recent response, pinning it into memory.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, 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 Code Map for information about this repository's layout and content.
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.