50b35193ec
Most of the support for valgrind was under HAVE_VALGRIND_VALGRIND_H, i.e. we would enable if the valgrind headers were found. The operations then we be conditionalized on RUNNING_UNDER_VALGRIND. But in a few places we had code which was conditionalized on VALGRIND, i.e. the config option. I noticed because I compiled with -Dvalgrind=true on a machine that didn't have valgrind.h, and the build failed because RUNNING_UNDER_VALGRIND was not defined. My first idea was to add a check that the header is present if the option is set, but it seems better to just remove the option. The code to support valgrind is trivial, and if we're !RUNNING_UNDER_VALGRIND, it has negligible cost. And the case of running under valgrind is always some special testing/debugging mode, so we should just do those extra steps to make valgrind output cleaner. Removing the option makes things simpler and we don't have to think if something should be covered by the one or the other configuration bit. I had a vague recollection that in some places we used -Dvalgrind=true not for valgrind support, but to enable additional cleanup under other sanitizers. But that code would fail to build without the valgrind headers anyway, so I'm not sure if that was still used. If there are uses like that, we can extend the condition for cleanup_pools(). |
||
---|---|---|
.clusterfuzzlite | ||
.github | ||
.semaphore | ||
catalog | ||
coccinelle | ||
docs | ||
factory | ||
hwdb.d | ||
LICENSES | ||
man | ||
mkosi.conf.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 | ||
.mailmap | ||
.packit.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
configure | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
meson_options.txt | ||
meson.build | ||
mkosi.build | ||
mkosi.kernel.config | ||
mkosi.postinst | ||
mkosi.prepare | ||
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 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.