041ea9f9bb
This drops the "const" specifier from the opaque object parameters to various functions in our API. This effectively reverts #19292 and more. Why drop this? Our public APIs should not leak too much information about how stuff is implemented internally. In our public APIs we shouldn't give too many guarantees we don#t want to necessarily keep. Specifically: in many cases it makes sense that getters actually generate/parse/allocate data on the fly, storing/caching the result internally, to speed things up, do things lazily or to track memory allocations so that they can be freed later. Doing this means we need to change the objects, even though the getters are semantically a read operation. We want to retain the freedom that we can change things around internally. By exposing the objects as "const" we remove a good chunk of that, for little gain. See sd_bus_creds_get_description() for a real example of a getter that implicitly caches and thus modifies the relevant object. This removes the "const" decorators from sd-dhcp and sd-netlink, two APIs that we intend to make public eventually even though they still are not, leaving us the chance to still fix this before it becomes set in stone. |
||
|---|---|---|
| .github | ||
| .lgtm/cpp-queries | ||
| .mkosi | ||
| .semaphore | ||
| catalog | ||
| coccinelle | ||
| docs | ||
| factory/etc | ||
| hwdb.d | ||
| man | ||
| mkosi.default.d | ||
| modprobe.d | ||
| network | ||
| po | ||
| presets | ||
| rules.d | ||
| shell-completion | ||
| src | ||
| sysctl.d | ||
| sysusers.d | ||
| test | ||
| tmpfiles.d | ||
| tools | ||
| units | ||
| xorg | ||
| .clang-format | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mailmap | ||
| .packit.yml | ||
| .vimrc | ||
| .ycm_extra_conf.py | ||
| configure | ||
| LICENSE.GPL2 | ||
| LICENSE.LGPL2.1 | ||
| Makefile | ||
| meson_options.txt | ||
| meson.build | ||
| mkosi.build | ||
| NEWS | ||
| README | ||
| README.md | ||
| TODO | ||
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 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.