This makes Request object takes hash, compare, free, and process functions.
With this change, the logic in networkd-queue.c can be mostly
independent of the type of the request or the object (e.g. Address) assigned
to the request, and it becomes simpler.
In most netlink handlers, we do the following,
1. decrease the message counter,
2. check the link state,
3. error handling,
4. update link state via e.g. link_check_ready().
The first two steps are mostly common, hence let's extract it.
Moreover, this is not only extracting the common logic, but provide a
strong advantage; `request_call_netlink_async()` assigns the relevant
Request object to the userdata of the netlink slot, and the request object
has full information about the message we sent. Hence, in the future,
netlink handler can print more detailed error message. E.g. when
an address is failed to configure, then currently we only show an
address is failed to configure, but with this commit, potentially we can
show which address is failed explicitly.
This does not change such error handling yet. But let's do that later.
This also renames e.g. request_process_address() -> address_process_request().
Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`,
as in the later commits, the function of processing request, e.g.
`address_process_request()`, will be assigned to the Request object when
it is created. And the request type will be used to distinguish and to
avoid deduplicating requests which do not have any assigned objects,
like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions
are mostly not necessary and redundant.
This is mostly cleanups and preparation for later commits, and should
not change any behavior.
All the detailed logging is replaced by a simple "Failed to create netlink message",
which should be enough for the user in the unlikely case that this ever fails.
This commit is the first in the series, and they generally follow the same
idea: we had very detailed logging for message append operations which would
only fail either with some type error or intrinsic limit (and then they would
fail everywhere, so this would be noticed during development or in CI), or they
would fail with ENOMEM, in which case the exact location is not very interesting
since this is not repeatable.
I am in general in favour of detailed logging messages, because it helps with
diagnosis of errors, but I think case is an exception. Despite not being very
useful, those messages required a lot of effort, because they were customized
for each and every append operation. In fact some of the messages contained copy
errors. The text of the messages (since they are generally unique) also added up
to a considerable size.
This removes the log messages after each sd_netlink_message_append_*() in
fill_message_create() with a single line in netdev_create(). As described
above, we are just appending fields to a message, so those calls would almost
never fail.
A forgotten 'return' was added in one place.
$ size build/systemd-networkd{.0,}
text data bss dec hex filename
1878634 394016 36 2272686 22adae build/systemd-networkd.0
1842450 394080 36 2236566 222096 build/systemd-networkd
… so we save 30k too.
But handle them gracefully. Otherwise, when the route to the address is
being configured, kernel refuse the route.
Note that kernel's wireguard module handle e.g. 192.168.10.3/24 as
192.168.10.0/24.
Fixes#21929.
Yu Watanabe
Luca Boccassi
Lennart Poettering
Zbigniew Jędrzejewski-Szmek