To make it work without sd-event.
Prompted by recent chat:
> Hey all!
> reading man libudev, it says to use sd-device instead now. I've read that
> APIs header file and it seems it no longer has an equivalent to libudev's
> udev_monitor_get_fd, which AFAICT means I have to use sd-event to watch
> for events I'm interested in. I know I can "embed" sd-event in other event
> loops I might already have, but that seems overkill when I'm only interested
> in this one type of event and don't need sd-event for anything else.
Previously, the main process of systemd-udevd manages worker process
with their sd_device_monitor object to save the destination address.
Let's save only destination address, and drop worker's sd_device_monitor
object.
Previously, device_monitor_enable_receiving() does
- update filter,
- bind socket.
But, binding socket can be done in when the socket is opened.
Let's remove device_monitor_enable_receiving() and bind the socket in
device_monitor_new_full().
The struct itself is generic, and can be used for other ID.
Let's rename it to more generic one.
No functional change, just refactoring and preparation for later
commits.
Since Linux commit ddd1ad68826d ("net: bridge: Add netlink knobs for number
/ max learned FDB entries") [1] it is possible to limit to number of
dynamically learned fdb entries per bridge.
Add support to the systemd networkctl for the netlink bridge attributes
IFLA_BR_FDB_MAX_LEARNED and IFLA_BR_FDB_N_LEARNED.
[1] https://lore.kernel.org/all/20231016-fdb_limit-v5-0-32cddff87758@avm.de/
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Since Linux commit ddd1ad68826d ("net: bridge: Add netlink knobs for number
/ max learned FDB entries") [1] it is possible to limit to number of
dynamically learned fdb entries per bridge.
Add support to the systemd netdev bridge for the new netlink attribute
IFLA_BR_FDB_MAX_LEARNED.
[1] https://lore.kernel.org/all/20231016-fdb_limit-v5-0-32cddff87758@avm.de/
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
This is a lot of stuff, and sometimes quite wild, let's turn this into
its own header.
All stuff color-related that just generates sequences is now in
ansi-color.h (no .c file!), and everything more complex that
probes/ineracts with terminals remains in termina-util.[ch]
This is a common case, and nothing noteworthy at all. For example, if we
establish an enumerator for listing all devices tagged by some tag, then
the per-tag dir is not going to exist if there are currently no devices
tagged that way, but that's a really common case, and doesn't really
deserve any mention, not even at debug level.
Our usual rule is that we are more lenient towards misuse for public
users of our code than for ourselves. Or in other words: when validating
parameters of our public functions (those starting with sd_…) we prefer
assert_ret() over assert().
It's time. sd-json was already done earlier in this cycle, let's now
make sd-varlink public too.
This is mostly just a search/replace job of epical proportions.
I left some functions internal (mostly IDL handling), and I turned some
static inline calls into regular calls.
Our variables for internal libraries are named 'libfoo' for the shared lib
variant, and 'libfoo_static' for the static lib variant. The only exception was
libbasic, because we didn't have a shared variant for it. But let's rename it
for consitency. This makes the build config easier to understand.
Use the new function `hashmap_ensure_replace()` where we're using
`hashmap_ensure_allocated()` and `hashmap_ensure_replace()`.
Signed-off-by: Matteo Croce <teknoraver@meta.com>
It's the same old story: 'struct sd_bus' is generally instantiated once, so
bitfields, for which we pay with more complicated code in all users of this
struct, are counterproductive. In some progs the structure may be instantiated
a few times, but it's still not worth it because we save a few bytes of memory
in one place and pay for this with many more bytes in the code.
$ size build/libsystemd.so.0.39.0{.orig,}
text data bss dec hex filename
2452757 65376 3768 2521901 267b2d build/libsystemd.so.0.39.0.orig
2451669 65376 3768 2520813 2676ed build/libsystemd.so.0.39.0
$ diff -u <(pahole build/libsystemd.so.0.39.0.orig) <(pahole build/libsystemd.so.0.39.0)
...
- /* size: 1960, cachelines: 31, members: 105 */
- /* sum members: 1944, holes: 3, sum holes: 9 */
- /* sum bitfield members: 25 bits, bit holes: 2, sum bit holes: 31 bits */
+ /* size: 1984, cachelines: 31, members: 105 */
+ /* sum members: 1971, holes: 4, sum holes: 13 */
/* member types with holes: 1, total: 1 */
i.e. 2452757 - 2451669 = 1088 extra bytes of code and slower execution, to save
24 bytes of memory per instance of the struct. (But the number of cachelines
doesn't change, so the smaller struct most likely has no effect on memory
access, and the alignment of the struct most likely means that the memory
saving is illusory too, we just end up with a few bytes of padding after the
struct.)
In the other structs, the alignment prevent the bitfield for having any effect
on memory use, but the compiler would still generate more complicated code,
i.e. we pay something for nothing.
For example:
$ diff -u <(pahole build/libsystemd.so.0.39.0.orig) <(pahole build/libsystemd.so.0.39.0)
...
struct node_callback {
struct node * node; /* 0 8 */
- _Bool is_fallback:1; /* 8: 0 1 */
+ _Bool is_fallback; /* 8 1 */
- /* XXX 7 bits hole, try to pack */
/* XXX 3 bytes hole, try to pack */
unsigned int last_iteration; /* 12 4 */
@@ -455,15 +448,13 @@
struct node_callback * callbacks_prev; /* 32 8 */
/* size: 40, cachelines: 1, members: 6 */
- /* sum members: 36, holes: 1, sum holes: 3 */
- /* sum bitfield members: 1 bits, bit holes: 1, sum bit holes: 7 bits */
+ /* sum members: 37, holes: 1, sum holes: 3 */
/* last cacheline: 40 bytes */
};
I kept the bitfield in sd_bus_slot because it prevents the struct from growing
from 112 to 120 bytes by reducing the alignment requirement for subsequent
fields, and we potentially can have this instantiated many times.
The arg types==NULL has different meanings for different functions. Some
functions like sd_bus_message_appendv() require a non-null param and treat "" as
"no data". Other functions like sd_bus_skip() treat null as "process one item",
while the convenience functions treat NULL the same as "". So I think it's
reasonable to make the convenience functions handle NULL explicitly, separately
from "". That way the logical separation of concerns is clearer, and e.g.
sd_bus_message_appendv() handles all non-null strings, while e.g.
sd_bus_call_methodv() doesn't look into the string at all.
Behaviour is unchanged.
Most of our enums are mapped to strings that use dashes ("-") as word
separators, i.e. "foo-bar-baz". However, Varlink enums do not allow "-"
as separator, see:
https://varlink.org/Interface-Definition
Hence, let's add some simple glue to automatucally turn "-" into "_" for
use when serializing our enums.
Update frameworks that work automatically in the background
occasionally need to schedule reboots. Systemd-logind already
provides a nice mechanism to schedule shutdowns, send notfications
and block logins short before the time. Systemd has a framework for
calendar events, so we may conveniently use logind to define a
maintenance time for reboots.
The existing ScheduleShutdown DBus method in logind expects a usec_t
with an absolute time. Passing USEC_INFINITY as magic value now tells
logind to take the time from the configured maintenance time if set.
"shutdown -r" leverages that and uses the maintenance time
automatically if configured. The one minute default is still used if
nothing was specified.
Similarly the new 'auto' setting for the --when parameter of systemctl
uses the maintenance time if configured or a one minute timer like the
shutdown command.
currently when dispatching json objects into C structs we either insist
on the field type or we don't. Let's extend this model a bit: depending
on two new fields either allow or refuse null types in addition to the
specified type.
This is useful for example when dispatch enums as this allows us
explicitly refuse null in various scenarios where we allow multiple
types.
The flag is fairly generic these days and just selects a slightly
stricter validation, with details depending on the selected dispatch
function. Hence, let's give it more precise name, in particular one that
mirrors the SD_JSON_RELAXED flag nicely (which does the opposite:
relaxes parsing)
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
Yu Watanabe
David Tardon
Gregor Herburger
Lennart Poettering
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Matteo Croce
Ludwig Nussel