In core, NMPlatform is (also) a singleton instance. As we will move platform code
to libnm-platform, this singleton part makes no sense there. Move the code
to NetworkManagerUtils.c.
It is a bit odd to do this, because usually libnm-glib-aux is not
about network related stuff. But that is not true entirely, because
it also contains NMIPAddr and other related helper funcitons.
NMLinkType is only a plain enum, there is no logic beyond it.
As such, I think it's acceptable to move it here.
There reason to do this, is that I want to move NMUtilsIPv6IfaceId and
nm_utils_get_ipv6_interface_identifier() out of src/core/, and since
that API is also trival helpers without complex state, it fits to
libnm-glib-aux. As such, we will need also NMLinkType there.
With systemd-resolved, NetworkManager considers `/etc/resolv.conf`
unmanaged. This breaks hostname lookups in a subtle way: when a new
connection comes online, NM will initiate the hostname lookup *before*
propagating DNS updates to systemd-resolved, which of course will cause
the request to fail. And because NM doesn't update `/etc/resolv.conf`,
it doesn't emit a `CONFIG_CHANGED` signal which would've restarted the
lookup.
Fix this by emitting a signal also when using a caching DNS plugin.
https://bugzilla.redhat.com/show_bug.cgi?id=1933863https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/770
Avoid dependencies but explicitly link the static library where it is
used.
This also fixes that we linked libnm-log-core into
libnm-settings-plugin-ifcfg-rh.so, which duplicated the symbols
while it should used them from NetworkManager.
We have a number of static helper libraries. When a user is using such a
library, they need to set the include search paths (-I) and link with
the static library at the right place.
The first part, the include search path, is now trivial. We no longer
add the individual search paths but everybody uses "-I. -Isrc/".
The second part means that when we build a shared library or an
executable that uses symbols from the static library, we need to link
it. But only then, and not earlier so that not multiple intermediate
build products (static libraries too) contain the same code. Note that
for libnm-device-plugin-*.so and other core plugins it's even that
those shared modules should not themselves link with the static
helpers. Instead, the need to use the symbols from NetworkManager.
Easy enough. Previously, we would sometimes define dependencies in
meson. But as it's really simple, I think that those dependencies
obfuscate more than help. Instead drop them, and only explicitly link
where we need it. The exception is libNetworkManagerTest_dep, which
is still a dependency. Maybe that dependency is fine, as it is much
later in the process. Or maybe that will also be replaced in the future.
This file was intended to be used by VPN plugins (by copying it).
However, it was also used internally.
Split the file, and move the internally used part to libnm-glib-aux.
The part that is only there for out of tree users, moves to
"nm-compat.h".
"nm-test-utils.h" is a header-only, helper library for our unit tests.
It was somewhat unmotivated in "shared/nm-utils", because all tests use
it, but it was not part of a "module".
Move it to "src/libnm-glib-aux/". It fits there very well. They both
have (only) a dependency on glib.
The bond option ad_actor_system only matters (and is available) with
mode=802.3ad.
When you create a new bond, the sysctl value will be set to "00:00:00:00:00:00".
So this seems to be a valid value, and in fact the default value for
this option. However, kernel will fail with EINVAL to set the sysctl to
"00:00:00:00:00:00". Kernel fails both if the value is already
"00:00:00:00:00:00" (i.e. setting the same value results in an error) and
it also fails otherwise (i.e. we cannot ever reset the value to
"00:00:00:00:00:00", at least not via sysfs).
Avoid the warning in the common case, where the value is already as
expected.
Otherwise, we still get the warning and won't be able to set the right
value. But this is really a limitation of the kernel API where we cannot
do anything about it (in NetworkManager).
https://bugzilla.redhat.com/show_bug.cgi?id=1923999
