This was requested in review:
https://github.com/systemd/systemd/pull/27846#discussion_r1210383265
I kept this as separate commit because the change would impact both of
the previous commits and splitting it up seems like unnecessary work.
The result is unchanged.
v2:
- use universal_newlines=True to keep compat with Python 3.6 on C8S.
No code change, just some splitting out of the relevant code from
udev-util.[ch].
This makes sense on its own, but is also prepartion to move the code
that checks for low battery state into battery-util.[ch], too.
The entries are sorted by speed. Some fields are left empty when there is no
clear value to use. The table is much longer now, but I think it's better to
document the allowed values, even if some are not terribly useful.
Fixes#26256.
We updated this table manually, but the kernel adds new modes periodically
and we forget to do that. So let that happen automatically whenever we import
new kernel headers.
C.f. 72dda93acb.
Effectively, this adds:
[ETHTOOL_LINK_MODE_10baseT1L_Full_BIT] = "10baset1l-full",
[ETHTOOL_LINK_MODE_800000baseCR8_Full_BIT] = "800000basecr8-full",
[ETHTOOL_LINK_MODE_800000baseKR8_Full_BIT] = "800000basekr8-full",
[ETHTOOL_LINK_MODE_800000baseDR8_Full_BIT] = "800000basedr8-full",
[ETHTOOL_LINK_MODE_800000baseDR8_2_Full_BIT] = "800000basedr8-2-full",
[ETHTOOL_LINK_MODE_800000baseSR8_Full_BIT] = "800000basesr8-full",
[ETHTOOL_LINK_MODE_800000baseVR8_Full_BIT] = "800000basevr8-full",
N_ADVERTISE needed to be increased because we need more bits.
crypsetup-fido2 always depended on both libfido2 and libcryptsetup, but
0a8e026e82 forgot to make the then
implicit dependency on libcryptsetup explicit when moving it from
cryptsetup/ to shared/. This breaks builds when libfido2 is autodetected
but the system is missing libcryptsetup.
Introduce an explicit check for HAVE_LIBCRYPTSETUP such that
cryptsetup-fido2 is only built when both libraries are available.
Fixes#27374.
This makes the bpf LSM check generic, so that we can use it elsewhere.
it also drops the caching inside it, given that bpf-lsm code in PID1
will cache it a second time a stack frame further up when it checks for
various other bpf functionality.
No functional change, just preparation for later commits.
These can be used in kernel-install later.
Note, unlike the our usual coding style, the arguments for
boot_entry_token_ensure() and parse_boot_entry_token_type() are
referenced, updated, and may freed, hence, always pass initialized
values. That's why they are not named as 'ret_xyz'.
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.
