It is only used by the assertion in event_queue_insert().
We have similar check e.g. in sd-bus or sd-event, but udevd.c is not a
library code, hence such check is not necessary.
The function manager_clear_for_worker() is now not called by workers,
and only called from manager_free(). Let's merge them.
This also drops unused Manager.rtnl, and outdated comment in
event_free().
While doing that, the Manager object allocated by the main process
is now _not_ freed in the spawned worker process, to follow our usual
coding style. See discussion in #24043.
The descriptions of various options are reworked: first say what protocol
actually is, i.e. describe what type of notification the manager waits
for. Only after that describe various steps and things the service should
do. Also, apply some paragraph breaks.
Instead of recommending Type=simple, recommend Type=exec. Say explicitly that
Type=simple, Type=forking are not recommended. Type=simple ignores failure in a
way that doesn't make any sense except as a historical accident. We introduced
'exec' instead of changing 'simple' to keep backwards-compatiblity, but
'simple' is not very useful. 'forking' works, but is inefficient: correctly
programming the interface requires a lot of work, and at runtime, the
additional one or two forks are just a waste of CPU resources. Furthermore, we
now understand that because of COW traps, they may also increase memory
requirements. There is really no reason to use 'forking', except if it's
already implemented and the code cannot be changed to use 'notify'.
Also, remove the recommendations to use Type=simple to avoid delaying boot. In
most cases, if the service can support notifications about startup, those
should be done.
Overall, for new services, "notify", "notify-reload", and "dbus" are the
types that make sense.
The logs would give no hint about the answer to most interesting question: why
we decided to return true or false from the program. If we find batteries
that are low or uncertain, log at info level.
The stub image may not have enough sections to cause enough PE header
space to be free for later expansion. Given that the stub is guaranteed
to be expanded we should always reserve enough sections for it.
This also bumps the reservation to 15. It doesn't add more space
compared to current builds but it more closely reflects the amount of
sections that a UKI could have in total if all optional sections are
used.
Fixes: #28593
The PE header size calculation failed to take the PE magic and coff
header size into account, which will lead to header truncation if we are
writing only 5 sections.
With the previous change, now Address objects under requesting are not
owned by Link object, hence we need to also search corresponding Address
object in the request queue.
Then, all addresses managed by a link really exist (unless the kernel
silently removes addresses).
By this change, now Address objects managed by Link and owned by Request
are decoupled, and always requested settings will be applied.
Fixes#25843.
This makes `manager_rtnl_process_address()`
- first read minimal information to get managed Address object,
- then update the managed Address object directly.
Previously, we updated the Address object managed by Link partially,
e.g. peer address did not updated.
This makes the managed Address object more consistent with the assigned
address.
The kernel manages neighbors by the destination address, and the
LinkLayerAddress is mutable. Let's manage neighbors in the same way, and
dedup settings.
Then, we can start IPv4ACD without adding corresponding Address object
to Link.
Hopefully, no functional change, just refactoring and preparation for
later commits.
Yu Watanabe
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Jan Janssen
Kiran Vemula
Frantisek Sumsal