Back in e2857b3d87 I added this function
as static inline in order to avoid linking libmount into libshared.
Nevertheless, a dependency on libmount was added to libbasic in
9e7f941acb, and later moved to libshared
in 77c772f227. So the shenanigan with an
inline function is not useful, let's make it a normal function.
version.h can be generated after compilation starts, creating a race condition
between compilation of various .c files and creation of version.h. Let's add it
as a dependency to more build targets that require version.h or build.h.
So far we played whack'a'mole by adding versiondep whenever compilation failed.
In principle any target which includes compilation (i.e. any that has .c
sources directly), could require this. I don't understand why we didn't see
more failures… But it seems reasonable to just add the dependency more widely.
In the Xen case, it's the hypervisor which manages kexec. We thus
have to ask it whether a kernel is loaded, instead of relying on
/sys/kernel/kexec_loaded.
Let's move the operator enum into its own .c/.h file, so that we can
reuse it elsewhere, in particular systemd-analyze's compare-versions
logic.
Let's rename the concept CompareOperator, since it is nowadays
genericlaly about both order *and* fnmatch comparisons, hence just
naming it "order" is misleading.
Introduce rootpkglibdir for installing libsystemd-{shared,core}.so.
The benefit over using rootlibexecdir is that this path can be
multiarch aware, i.e. this path can be architecture qualified.
This is something we'd like to make use of in Debian/Ubuntu to make
libsystemd-shared co-installable, e.g. for i386 the path would be
/usr/lib/i386-linux-gnu/systemd/libsystemd-shared-*.so and for amd64
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-*.so.
This will allow for example to install and run systemd-boot/i386 on an
amd64 host. It also simplifies/enables cross-building/bootstrapping.
For more infos about Multi-Arch see https://wiki.debian.org/Multiarch.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
We already store the dlopen() stuff for other libraries in util headers
as well so let's do the same for pcre2. We also move the definition of
some trivial cleanup functions from journalctl.c to pcre2-util.h
That file only exported one function, and it fits nicely within the scope of
"parse helpers". Let's move it there to reduce the file count a bit.
No functional change.
This is a high-level function, and it belongs in libsystemd-shared. This way we
don't end up linking a separate copy into various binaries. It would even end
up in libsystemd, where it is not needed. (Maybe it'd be removed in some
optimization phase, but it's better to not rely on that.)
$ grep -l -r -a 'path is not absolute%s' build/
build/libnss_systemd.so.2
build/pam_systemd_home.so
build/test-dlopen
build/src/basic/libbasic.a.p/path-util.c.o
build/src/basic/libbasic.a
build/src/shared/libsystemd-shared-249.so
build/test-bus-error
build/libnss_mymachines.so.2
build/pam_systemd.so
build/libnss_resolve.so.2
build/libnss_myhostname.so.2
build/libsystemd.so.0.32.0
build/libudev.so.1.7.2
$ grep -l -r -a 'path is not absolute%s' build/
build/src/shared/libsystemd-shared-251.a.p/parse-helpers.c.o
build/src/shared/libsystemd-shared-251.a
build/src/shared/libsystemd-shared-251.so
No functional change.
Some refactoring: split efi-loader.[ch] in two: isolate the calls that
implement out boot loader interface spec, and those which implement
access to upstream UEFI firmware features.
They are quite different in nature and behaviour, and even semantically
it makes to keep these two separate. At the very least because the
previous name "efi-loader.[ch]" suggests all was about loader-specific
APIs, but much of it is generic uefi stuff...
While we are at it, I renamed a bunch of return parameters to follow our
usual ret_xyz naming. But besides renaming no real code changes.
The code is quite different from the rest of bootspec.c, with different
deps and stuff. There's even a /***/ line to separate the two parts.
Given how large the file already is, let#s just split it into two.
No code changes, just some splitting out.
The approach to use '''…'''.split() instead of a list of strings was initially
used when converting from automake because it allowed identical blocks of lines
to be used for both, making the conversion easier.
But over the years we have been using normal lists more and more, especially
when there were just a few filenames listed. This converts the rest.
No functional change.
Add dlopen_dw(), dlopen_elf() and dlopen_pcre2() to the dlopen test.
To enable adding dlopen_pcre2(), we move pcre2-dlopen.h/c from
src/journal to src/shared.
We have /usr/lib/systemd/libsystemd-{shared,core}-nnn.so. With this
path the 'nnn' part can be changed to something different. The idea
is that during a package build this will be set to the package version.
This way during in-place upgrades with the same major version both
the new and old libraries can cooexit. This should fix the issue
when systemd programs are called during package upgrades and fail
to exec because the expect different symbols in the library they
are linked to.
This should fix https://bugzilla.redhat.com/show_bug.cgi?id=1906010.
The scheme is very similar to libsystemd-shared.so: instead of building a
static library, we build a shared library from the same objects and link the
two users to it. Both systemd and systemd-analyze consist mostly of the fairly
big code in libcore, so we save a bit on the installation:
(-0g, no strip)
-rwxr-xr-x 5238864 Dec 14 12:52 /var/tmp/inst1/usr/lib/systemd/systemd
-rwxr-xr-x 5399600 Dec 14 12:52 /var/tmp/inst1/usr/bin/systemd-analyze
-rwxr-xr-x 244912 Dec 14 13:17 /var/tmp/inst2/usr/lib/systemd/systemd
-rwxr-xr-x 461224 Dec 14 13:17 /var/tmp/inst2/usr/bin/systemd-analyze
-rwxr-xr-x 5271568 Dec 14 13:17 /var/tmp/inst2/usr/lib/systemd/libsystemd-core-250.so
(-0g, strip)
-rwxr-xr-x 2522080 Dec 14 13:19 /var/tmp/inst1/usr/lib/systemd/systemd
-rwxr-xr-x 2604160 Dec 14 13:19 /var/tmp/inst1/usr/bin/systemd-analyze
-rwxr-xr-x 113304 Dec 14 13:19 /var/tmp/inst2/usr/lib/systemd/systemd
-rwxr-xr-x 207656 Dec 14 13:19 /var/tmp/inst2/usr/bin/systemd-analyze
-rwxr-xr-x 2648520 Dec 14 13:19 /var/tmp/inst2/usr/lib/systemd/libsystemd-core-250.so
So for systemd itself we grow a bit (2522080 → 2648520+113304=2761824), but
overall we save. The most is saved on all the test files that link to libcore,
if they are installed, because there's 15 of them:
$ du -s /var/tmp/inst?
220096 /var/tmp/inst1
122960 /var/tmp/inst2
I also considered making systemd-analyze a symlink to /usr/lib/systemd/systemd
and turning systemd into a multicall binary. We did something like this with
udevd and udevadm. But that solution doesn't fit well in this case.
systemd-analyze has a bunch of functionality that is not used in systemd,
so the systemd binary would need to grow quite a bit. And we're likely to
add new types of verification or introspection features in analyze, and this
baggage would only grow. In addition, there are the test binaries which also
benefit from this.
The meson default for static_library() are:
build_by_default=true, install=false. We never interact with the
static libraries, and we only care about them as a stepping-stone towards
the installable executables or libraries. Thus let's only build them if
they are a dependency of something else we are building.
While at it, let's drop install:false, since this appears to be the default.
This change would have fixed the issue with lib_import_common failing
to build too: we wouldn't attempt to build it.
In practice this changes very little, because we generally only declare static
libraries where there's something in the default target that will make use of
them. But it seems to be a better pattern to set build_by_default to false.
In order to avoid inflating the dependency list for the core
library, use dlopen when inspecting elfs, since it's only
used in two non-core executables.
Previously the mkdir_label() family of calls was implemented in
src/shared/mkdir-label.c but its functions partly declared ins
src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird
(and wrong).
Let's clean this up, and add a proper mkdir-label.h matching the .c
file.
user-record.[ch] are about the UserRecord JSON stuff, and the UID
allocation range stuff (i.e. login.defs handling) is a very different
thing, and complex enough on its own, let's give it its own c/h files.
No code changes, just some splitting out of code.
This adds to new helpers: keyring_read() for reading a key data from a
keyring entry, and TAKE_KEY_SERIAL which is what TAKE_FD is for fds, but
for key_serial_t.
The former is immediately used by ask-password-api.c
This adds a bit of generic helper tools for installing files/dir trees.
"installing" is supposed to mean the final step when preparing a disk
image or directory tree, where the result is renamed to its final name.
It has some bells and whistles, as it is able to replace existing files
sanely, can fsync() things carefully and can mark things read-only in a
nice way.
This is supposed to be generic, unified code that can be used eventually
for any of our tools that prepare disk images/directory trees, including
importd, nspawn's --template= mechanism, the discover-image.c logic,
and more.
This is preparation for adding encryption support to the credentials
logic, and we thus would like to add more deps. Let's hence move things
from src/basic/ to src/shared, so that we can rely on the OpenSSL
utilities already in src/shared.
Parse address family, ip protocol and ports, any of them can be
optional. If neither is specified, a special value 'any' is expected.
Helper is placed in shared to be reused in both fragment and dbus.
Add unit tests with valid and invalid examples.
The goal is to move everything that requires selinux or smack
away from src/basic/. This means that src/basic/label.[ch] must move,
which implies btrfs-util.[ch], copy.[ch], and a bunch of other files
which form a cluster of internal use.
This is just moving text around, so there should be no functional difference.
test-blockdev-util is new, because path_is_encrypted() is moved to
blockdev-util.c, and so far we didn't have any tests for code there.