Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
NMUdevClient does not actually implement ref-counting, because it's not
used. Still, the destroy function was named nm_udev_client_unref(),
because theoretically then we could later, as the need arises, make
the type ref-counted. Then unref function already had the right name.
However, NMUdevClient also has a callback function that emits monitor
events. Again for simplicity, this callback function cannot be reset, it
can only be set once (in the constructor) and can also not be unset nor
disabled.
When the user of NMUdevClient is done with the instance and calls
"unref", then it must be sure that the callback is no longer invoked
afterwards. In practice that is already the case, but "unref" makes it
sound as if somebody else could also still hold a reference -- in which
case the user would have to first unset/disable the callback.
Rename the function to "destroy()", so that it's clear that the instance
is gone afterwards and that the callback will not be invoked anymore.
In some cases the enslavement event of a device gets
processed by nm-platform before the master NMDevice is
created, in such cases the enslavement information is simply
lost by NM, to prevent this let NMDevice connect to the
'device-ifindex-changed' signal to be notified of when its master
NMDevice appears so that eventually the NMDevices will be consistent
with the kernel network state.
https://bugzilla.redhat.com/show_bug.cgi?id=1870691
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Bonds need to release all enslaved devices when
the bond mode is to be changed.
Also release slaves when they're external interfaces as
it means the master it's now managed by NetworkManager.
https://bugzilla.redhat.com/show_bug.cgi?id=1870691
Signed-off-by: Antonio Cardace <acardace@redhat.com>
This is the default state for new devices hence they should
return back to this state when unmanaged.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Sometimes the option can't be displayed as is because it contains NULL
or non-ascii characters. Rename the 'hidden' argument of
nm_supplicant_config_add_option_with_type() to 'display_value' so that
callers can pass a preferred string representation of the value.
- the python-black version on Fedora 33 was updated, and this formats
our python code differently. The black version that is used by our
gitlab-ci is the authoritative version that should be used. Update
it by regenerating the containers.
- especially Fedora:rawhide and Debian:sid often introduce changes that
will cause a break of our build. Update the containers to test latest
versions.
Fedora 33's version of python-black is the authoritative version we
use for formatting -- note that formatting may look different depending
on the black version.
Recently, the package was updated to 20.8~b1-1.fc33, which treats
these lines different.
Work around that by adjusting the code so that both older and current
versions of python black behave the same.
We have many static helper libraries, like libnm-glib-aux or libnm-core.
These can be statically linked in any end-binary as internal API. However, they
must only be linked once.
Also, we have various plugins (device, settings, ppp, wwan) which are
dlopened by NetworkManager. They should use the symbols from
NetworkManager core. It is important that they do not link with the
static libraries already, because also NetworkManager core links with
it, so these symbols will be duplicate.
As the symbols are internal, you might think that it is not a real
problem to duplicate them. However, there are also global variables,
like the hash tables for NMRefStr or the seed for NMHash. These global
variables must be only be used once, and hence also these symbols must
no be duplicated.
Fix that by adding a new dependency that is for the core plugins. This
dependency only has "include_directories" but not "link_with".
Naming for us is hard, because everything is an "nm". However, let's
standardize on the term "core" for the daemon, and not "daemon".
Eventually I would like to move the daemon from "src/" to "src/core/",
rename the dep in anticipation of that.
A timeout for tests should not be reached anyway. It's only
a fail-safe for not running indefinitely (and for meson not killing
the test too early). We don't need to run test-libnm with a shorter
timeout.
This is basically all of libnm as a static-library. The name
liblibnm isn't great. Arguably, we do have quite a lot of
libnmxyz, so finding a good name is hard. But libnm-static seems
a better name. Rename.
Drop some "helper" variables that are only used once. These variables
spread out what is defined, and only make the meson file more complicated
to follow.
OVS system interfaces can start to connect even before the ovsdb is
ready. However, the connection attempt is doomed to fail and the
NMSettingsConnection gets blocked with reason FAILED.
Unblock them once the ovsdb is ready.
Ideally, NMPolicy should subscribe to the NMOvsdb::ready signal,
however NMOvsdb is in a plugin, so it's easier if NMOvsdb directly
calls a function of the core.
Sometimes during boot the device starts an activation with reason
'assumed', then the ovs interfaces gets removed from the ovsdb. At
this point the device has an active-connection associated; it has the
activate_stage1_device_prepare() activation source scheduled, but it
is still in disconnected state.
Currently the factory doesn't recognizes that the device is activating
and allows the device to proceed even if the interface was removed
from the ovsdb. Fix this by checking the presence of an
active-connection instead.
During shutdown, NM always tries to remove from ovsdb all bridges,
ports, interfaces that it previously added. Currently NM doesn't run
the main loop during shutdown and so it's not possible to perform
asynchronous operations. In particular, the NMOvsdb singleton is
disposed in a destructor where it's not possible to send out all the
queued deletions.
The result is that NM deletes only one OVS interface, keeping the
others. This needs to be fixed, but requires a rework of the shutdown
procedure that involves many parts of NM.
Even when a better shutdown procedure will be implemented, we should
support an unclean shutdown caused by e.g. a kernel panic or a NM
crash. In these cases, the interfaces added by NM would still linger
in the ovsdb.
Delete all those interface at NM startup. If there are connections
profiles for them, NM will create them again.
Also, NMOvsdb now emits a NM_OVSDB_READY signal and provides a
nm_ovsdb_is_ready() to allow other parts of the daemon to order
actions after the initial OVS cleanup.
https://bugzilla.redhat.com/show_bug.cgi?id=1861296https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/700
