IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We recently started making more use of malloc_usable_size() and rely on
it (see the string_erase() story). Given that we don't really support
sytems where malloc_usable_size() cannot be trusted beyond statistics
anyway, let's go fully in and rework GREEDY_REALLOC() on top of it:
instead of passing around and maintaining the currenly allocated size
everywhere, let's just derive it automatically from
malloc_usable_size().
I am mostly after this for the simplicity this brings. It also brings
minor efficiency improvements I guess, but things become so much nicer
to look at if we can avoid these allocation size variables everywhere.
Note that the malloc_usable_size() man page says relying on it wasn't
"good programming practice", but I think it does this for reasons that
don't apply here: the greedy realloc logic specifically doesn't rely on
the returned extra size, beyond the fact that it is equal or larger than
what was requested.
(This commit was supposed to be a quick patch btw, but apparently we use
the greedy realloc stuff quite a bit across the codebase, so this ends
up touching *a*lot* of code.)
This is a wrapper around malloc_usable_size() but is typesafe, and
divides by the element size.
A test it is also added ensuring what it does it does correcly.
It's a wrapper around malloc_usable_size() that is supposed to be
compatible with _FORTIFY_SOURCES=1, by taking the
__builtin_object_size() data into account, the same way as the
_FORTIFY_SOURCES=1 logic does.
Fixes: #19203
m4 is required to build the test SELinux module:
```
[ 31.321789] sh[483]: /bin/sh: line 1: m4: command not found
[ 31.882668] sh[488]: Compiling targeted systemd_test module
[ 32.120862] sh[492]: /bin/sh: line 1: m4: command not found
[ 32.159897] sh[458]: make: *** [/usr/share/selinux/devel/include/Makefile:156: tmp/systemd_test.mod] Error 127
```
... and /usr/bin/ path for a library package which provides an executable we
care about (libxslt).
This way the mkosi dependency list corresponds directly to the names which are
used in the dependency() and find_program() lines in meson.build. It also makes
the thing more resilient to package splits and renames.
In case the link online state is invalid, networkctl will print
"unknown", which is sufficiently neutral. The same goes for the overall
manager online state if there are no managed links, or if
RequiredForOnline=no for all managed links.
Example output:
$ networkctl status
● State: routable
Online state: partial
Address: 172.22.0.130 on wlan0
...
$ networkctl status wlan0
● 3: wlan0
Link File: /lib/systemd/network/99-default.link
Network File: /etc/systemd/network/50-wlan0.network
Type: wlan
State: routable (configured)
Online state: online
...
With new "online state" semantics in networkd, make the description of
RequiredFamilyForOnline= a little more broad. Some rewording has been
done to make the passage easier to understand.
Since networkd advertises a reliable online state, use it in
network_is_online(). If for some reason networkd does not know the
online state (e.g. it does not manage any of the network interfaces),
fall back to the original best-guess logic.
Add a new state of type LinkOnlineState which indicates whether a link
is online or not. The state is also used by networkd's manager to expose
the overall online state of the system.
The possible states are:
offline the link (or system) is offline
partial at least one required link is online (see below)
online all required links are online
For links, a link is defined to be "online" if:
- it is managed; and
- its operational state is within the range defined by
RequiredForOnline=; and
- it has an IPv4 address if RequiredFamilyForOnline=ipv4 or =both; and
- it has an IPv6 address if RequiredFamilyForOnline=ipv6 or =both.
A link is defined to be "offline" if:
- it is managed; and
- it is not online, i.e. its operational state is not within the range
defined by RequiredForOnline=, and/or it is missing an IP address in
a required address family.
Otherwise, the link online state is undefined (represented internally as
_LINK_ONLINE_STATUS_INVALID or -EINVAL). Put another way, networkd will
only offer a meaningful online state for managed links where
RequiredForOnline=yes.
For the manager, the online state is a function of the online state of
all links which are requried for online, i.e. RequiredForOnline=yes. If
all required links are online, then the manager online state is defined
to be "online". If at least one of the required links is online, then
the manager online state is defined to be "partial". If none of
the required links are online, then the manager online state is defined
to be "offline". If there are no managed links, or RequiredForOnline=no
for all managed links, then the manager online state is undefined as
above.
The purpose of the "partial" state is analogous to the --any switch in
systemd-networkd-wait-online.service(8). For example, a required link
which lacks a carrier on boot will not force the overall (manager)
online state to "offline" if there is an alternative link available.
Recent meson versions include the directory name in the target name,
so there is no conflict for files with the same name in different
directories. But at least with meson-0.49.2 in buster we have conflict
with sysusers.d/systemd.conf.
This doesn't matter too much, but makes things a bit more consistent.
A minor advantage is that the file is not a configuration file for meson
anymore, so:
a) It is not built unless pulled in by another target. Since
we don't usually build man pages by default, this saves a tiny
amount of work.
b) When the .in file is updated, meson does not reconfigure everything,
but just rebuilds the dependent targets.
Now that the conversion is finished, time for benchmarking:
a full build with default settings (and -Dstandalonebinaries=true), yields
before this pull request: 1687 targets, 148.13s user 35.17s system 317% cpu 57.697 total
with the full pull request: 1714 targets, 143.07s user 27.87s system 314% cpu 54.369 total
The difference doesn't seem significant. Partial rebuilds might be faster as
mentioned before.
We had two big 'configuration_data' objects in meson config. (There are in fact
more. On is added in this series, and there's one for efi… But those others
have a handful variables only for specific purposes and don't matter). The two
sets are 'conf' and 'substs', and were inherited from the original autotools
system. In the past there was even a third set ('m4_defines'), but @yuwata
removed it in 348b44372f36010d48d9a7dda14ef67155753a71. And those two/three
systems had very similar data, but with different variable names, because of
historical reasons. They also used subtly different quoting (.set()
vs. .set10() vs. .set_quoted()), which was required because the templating
engines were not flexible enough. This meants we had more work when changing
things, and we needed to search for different variable names, etc.
With a more flexible templating engine we can do with just one
configuration_data object.
