99839c7ebd
C macros are nasty. We use them, but we try to be conservative with them. In particular passing literal, complex code blocks as argument is icky, because of "," handling of C, and also because it's quite a challange for most code highlighters and similar. Hence, let's avoid that. Using macros for genreating functions is OK but if so, the parameters should be simple words, not full code blocks. hence, rework DEFINE_CUSTOM_TEST_MAIN() to take a function name instead of code block as argument. As side-effect this also fixes a bunch of cases where we might end up returning a negative value from main(). Some uses of DEFINE_CUSTOM_TEST_MAIN() inserted local variables into the main() functions, these are replaced by static variables, and their destructors by the static destructor logic. This doesn't fix any bugs or so, it's just supposed to make the code easier to work with and improve it easthetically. Or in other words: let's use macros where it really makes sense, but let's not go overboard with it. (And yes, FOREACH_DIRENT() is another one of those macros that take code, and I dislike that too and regret I ever added that.) |
||
|---|---|---|
| .clusterfuzzlite | ||
| .github | ||
| .lgtm/cpp-queries | ||
| .semaphore | ||
| catalog | ||
| coccinelle | ||
| docs | ||
| factory | ||
| hwdb.d | ||
| LICENSES | ||
| 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 | ||
| mkosi.postinst | ||
| 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.