On Fedora rawhide (34), valgrind gives a lot of warnings like:

    ./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- WARNING: unhandled amd64-linux syscall: 439
    ./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- You may be able to write your own handler.
    ./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
    ./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- Nevertheless we consider this a bug.  Please report
    ./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- it at http://valgrind.org/support/bug_reports.html.

Ignore them.

Otherwise, the test generates an "messages.mo" file.

Fixes: 97c1bed3 ('build: add test for valid po files (msgfmt -vc)')

If the connection doesn't specify a master, ensure that the device is
released from any master in platform.

https://bugzilla.redhat.com/show_bug.cgi?id=1869079
NetworkManager/NetworkManager!616

NetworkManager/NetworkManager!618

NMDBusObject is an abstract type which provides the glue code for exposing
a GObject on D-Bus. We almost never use that type directly, so as it was
before, we always had to use a C cast to convince the compiler that this
is right.

Being always required to cast is not very useful, nor more typesafe.
Just use a void pointer instead.

NML3Cfg manages one ifindex. In the future, we may want that multiple
NMDevice and/or NMVpnConnection instances independently contribute their
NML3ConfigData to the NML3Cfg instance.

That means, at any time somebody may want to call nm_l3cfg_platform_commit()
to apply the changes. Even ACD internally may do that, when configuration
changes (e.g. an IP address passes ACD check). We thus need to know
whether we are assuming, updating or reapplying the settings.

Add API so users can register their "commit" preference.

Add more code that will be used later for glueing NMDevice with NML3Cfg
and NML3ConfigData. The code is not yet really used.

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.

We will need to prune routes that kernel adds (and we don't want).

NetworkManager/NetworkManager#526

NetworkManager/NetworkManager!619

And `make -C po update-po` to regenerate the default.

NetworkManager/NetworkManager!612

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.

This will only have one particular use, from NNL3Cfg. However, it seems
general enough to place it in "nm-platform.h".

Having leaks in the tests, breaks running the test under valgrind. There
must be no leaks.

Fixes: c056cb93 ('initrd: parse 'rd.net.dhcp.vendor-class' kernel cmdline arg')

Signed-off-by: Antonio Cardace <acardace@redhat.com>

Signed-off-by: Antonio Cardace <acardace@redhat.com>

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.

Signed-off-by: Antonio Cardace <acardace@redhat.com>

Fixes: 0aa09da5 ('man: explain "/var/lib/NetworkManager/secret-key" in `man NetworkManager`')