For PID 1 we adjust the umask to 0, but generators should not run that
way, given that they might be implemented as shell scripts and such.
Let's hence explicitly adjust the umask for them.
We already do this for unit generators. Let's do this for env
generators, too.
Let's not bother contributors with spurious failures nobody can't
seem to reproduce. There is an issue about that where we're trying
to figure out what's going on: https://github.com/systemd/systemd/issues/10696.
The rule is changed from "put in basic unless there's a reason not to" to "put
in shared unless there's a reason not to", to match the change done in previous
commit. This minimizes libbasic. See previous commit for the reasons why this
is useful.
Previously, the guideline was based on whether the files in question use
"publicly exported APIs". This distinction is not particularly relevant. Let's
consider all other programs we compile: most of them use "publicly exported
APIs", usually linking to libsystemd-shared.so for the actual code. But those
programs are not forced to be in src/basic, and the distinction whether they
happen to use 'sd-*.h' or not is of no importance. The same is true for files
in src/shared/. If we didn't have publicly exported shared objects, we'd put
everything in libsystemd-shared.so. So let's only move things out of it that we
need to. Previous guideline was not "wrong", in the sense that it created *a*
split that was functional (no code in src/shared was required in the publicly
exported shared objects), but it put more files in basic/ then necessary.
Not much changes in practice, because (as previous commit shows), moving files
between libbasic.a and libsystemd-shared.so mostly just changes compilation
order.
The list of components which cannot use libsystemd-shared.so is adjusted.
This doesn't have much effect on the final build, because we link libbasic.a
into libsystemd-shared.so, so in the end, all the object built from basic/
end up in libsystemd-shared. And when the static library is linked into binaries,
any objects that are included in it but are not used are trimmed. Hence, the
size of output artifacts doesn't change:
$ du -sb /var/tmp/inst*
54181861 /var/tmp/inst1 (old)
54207441 /var/tmp/inst1s (old split-usr)
54182477 /var/tmp/inst2 (new)
54208041 /var/tmp/inst2s (new split-usr)
(The negligible change in size is because libsystemd-shared.so is bigger
by a few hundred bytes. I guess it's because symbols are named differently
or something like that.)
The effect is on the build process, in particular partial builds. This change
effectively moves the requirements on some build steps toward the leaves of the
dependency tree. Two effects:
- when building items that do not depend on libsystemd-shared, we
build less stuff for libbasic.a (which wouldn't be used anyway,
so it's a net win).
- when building items that do depend on libshared, we reduce libbasic.a as a
synchronization point, possibly allowing better parallelism.
Method:
1. copy list of .h files from src/basic/meson.build to /tmp/basic
2. $ for i in $(grep '.h$' /tmp/basic); do echo $i; git --no-pager grep "include \"$i\"" src/basic/ 'src/lib*' 'src/nss-*' 'src/journal/sd-journal.c' |grep -v "${i%.h}.c";echo ;done | less
Code was not doing a wait() after kill() due to checking for a return value > 0, and was leaving zombie processes. This affected things like sd-bus unixexec connections.
As suggest here:
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
"You may optionally specify attribute names with ‘__’ preceding and
following the name. This allows you to use them in header files without
being concerned about a possible macro of the same name. For example,
you may use the attribute name __noreturn__ instead of noreturn. "
Let's use the correct wrapper for calling unit vtable functions. Let's
make sure we always use the right wrappers, and never bypass them
needlessly.
Moreover use SIGKILL rather than "9" as signal name. Let's not be
needlessly cryptic.
Follow-up for: f7f8e8cbb9
The existing text already said "See below regarding a recommended
vocabulary for boot loader entry identifiers.", but the section for it
was still missing. Let's fill in the missing bits, and describe basic
suggested rules for the boot menu entry identifier vocabulary, in
particular how to identify Windows and MacOS X installations, and how to
name automatic entries vs. explicitly configured ones.
This basically follows the logic implemented in sd-boot these days.
Yu Watanabe
Lennart Poettering
Evgeny Vereshchagin
Zbigniew Jędrzejewski-Szmek
Xuanwo
David Leeds