The current approach also tracks external configuration in an NMIP[46]Config, and
we need to special handle those. In the future, we only want to track what we actually
want to configure. So this flag won't be used with NML3Cfg/NML3ConfigData.
Currently, NMDevice does ACD. It intercepts certain NMIP4Config
instances, and tries to perform ACD on the addresses. I think this
functionality should be handled by NML3Cfg instead.
For one, NML3Cfg sees all configurations, and can perform ACD for all
(relevant) addresses. Also, it moves logic away from NMDevice and makes
the functionality available without an NMDevice. As such, it also will
allow that independent "controllers" contribute NML3ConfigData instances
and ACD will performed for all of them (as requested).
This will be our implementation for IPv4 ACD (https://tools.ietf.org/html/rfc5227)
based on nettools' n-acd library.
The code is not actually tested yes, because NMDevice did not yet switch
over to use NML3Cfg. Once that happens, surely issues with this patch
will be found that will need fixing.
Having leaks in the tests, breaks running the test under valgrind. There
must be no leaks.
Fixes: c056cb9306 ('initrd: parse 'rd.net.dhcp.vendor-class' kernel cmdline arg')
We still use the "gs_*" macros that we originally got from libgsystem.
libgsystem no longer exists, we only still use the names of these
macros.
Our own cleanup macros all follow the "nm_auto*" naming pattern.
Eventually, we want to replace all uses of "gs_*" with cleanup macros
that follow our naming scheme.
Add the macros that will be used to replace the "gs_*" macros.
The "gs_*" macros originate from the (no longer existing) libgsystem library.
We still have them, because so far we didn't go through the effort of
renaming the API.
Aside that oddity, our cleanup API is called "nm_auto*". There is no need
to add new API with the old name.
When a virtual device fails, its state goes to FAIL and then
DISCONNECTED. In DISCONNECTED we call schedule_activate_check() to
schedule an auto-activation if needed. We also schudule the deletion
of the link through delete_on_deactivate_check_and_schedule(). The
auto-activation attempt fails because the link deletion unmanages the
device; as a result, the device doesn't try to auto-activate again.
To fix this:
- don't allow the device to auto-activate if the device deletion is
pending;
- check again if the device can be auto-activated after its deletion.
https://bugzilla.redhat.com/show_bug.cgi?id=1818697https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/613
With LTO we get a compiler warning:
src/dhcp/nm-dhcp-systemd.c: In function dhcp_event_cb:
src/dhcp/nm-dhcp-systemd.c:554: error: lease may be used uninitialized in this function [-Werror=maybe-uninitialized]
554 | r = sd_dhcp_lease_get_server_identifier (lease, &addr);
|
src/dhcp/nm-dhcp-systemd.c:528: note: lease was declared here
528 | sd_dhcp_lease *lease;
|
Fixes: 7f217d0345 ('core: honor the ipv4.dhcp-reject-servers property')
Avoids a compiler warning:
../src/devices/nm-device.c:16079:26: error: cast to smaller integer type 'NMDeviceStateReason' from 'gpointer' (aka 'void *') [-Werror,-Wvoid-pointer-to-enum-cast]
deactivate_ready (self, (NMDeviceStateReason) reason);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 121c58f0c4 ('core: set number of SR-IOV VFs asynchronously')
"XXX" is used for tagging parts of code that still need work before
merging a patch. If you want to highlight/mark a comment which is merged
use either "TODO" or "FIXME".
Of course, even "TODO" and "FIXME" should be avoided in favor of just
doing/fixing it. Such things tend to never be done/fixed.
