Currently, all Request object are always owned by Manager, and freed
when it is processed, especially, soon after a netlink message is sent.
So, it is not necessary to introduce the reference counter.
In a later commit, the Request object will _not_ be freed at the time
when a netlink message is sent, but assigned to the relevant netlink
slot as a userdata, and will be freed when a reply is received. So, the
owner of the Request object is changed in its lifetime. In that case, it
is convenient that the object has reference counter to avoid memleak or
double free.
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.
This should not change any behavior, as req->netlink_handler is always
qdisc_handler or tclass_handler.
This is just a preparation for a later commit which introduces
request_call_netlink_async().
The string will be used when the client load additional config file to
boot, and it must be a valid path or url. Hence, let's refuse non-safe or
non-characters.
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.
Previously, the broadcast address was set to a Address object in
address_section_verify() (or address_acquire()). But, for wireguard
interfaces, we do not use the broadcast address. The .network file may
be assigned to multiple interfaces, hence, we cannot determine if we
should set the broadcast address in address_section_verify().
This makes the broadcast address set in link_request_address().
Then, we set the broadcast address only when we need it.
This re-introduce the full hash and compre functions for Address,
which was reverted 1d30fc5cb6 (#17851).
The issue #17831, which is fixed by #17851, is handled in a different way;
simply ignore to configure the conflicted DHCPv6 address. Previously, we
warn about the conflict, but continue to configure the address anyway, and
the kernel ignores the request. So, it is not necessary to request the
conflicted address in networkd side.
This fixes the following issues:
- when a link has an address, and corresponding .network file has the
address with different prefix length, then the prefix length specified
in the .network file will not be applied,
- we cannot specify multiple IPv4 addresses with different prefix
length, e.g.
----
Address=10.10.10.10/24
Address=10.10.10.10/16
----
This is spurious setup, but the kernel allows it.
Fixes#22515.
There is no reason networkd refuses that. Especially, when multiple
downstream interfaces are connected to the same network, it is natural to
assign the same subnet prefix to them.
Prompted by #22571.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Luca Boccassi