$ find * -type f |xargs perl contrib/scripts/spdx.pl
  $ git rm contrib/scripts/spdx.pl

We no longer add these. If you use Emacs, configure it yourself.

Also, due to our "smart-tab" usage the editor anyway does a subpar
job handling our tabs. However, on the upside every user can choose
whatever tab-width he/she prefers. If "smart-tabs" are used properly
(like we do), every tab-width will work.

No manual changes, just ran commands:

    F=($(git grep -l -e '-\*-'))
    sed '1 { /\/\* *-\*-  *[mM]ode.*\*\/$/d }'     -i "${F[@]}"
    sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"

Check remaining lines with:

    git grep -e '-\*-'

The ultimate purpose of this is to cleanup our files and eventually use
SPDX license identifiers. For that, first get rid of the boilerplate lines.

==6207== Syscall param ioctl(SIOCETHTOOL) points to uninitialised byte(s)
==6207==    at 0x514603B: ioctl (syscall-template.S:78)
==6207==    by 0x19FC2F: _ioctl_call (nm-platform-utils.c:183)
==6207==    by 0x1A026B: _ethtool_call_handle (nm-platform-utils.c:319)
==6207==    by 0x1A031F: ethtool_get_stringset (nm-platform-utils.c:378)
==6207==    by 0x1A03BC: ethtool_get_stringset_index (nm-platform-utils.c:414)
==6207==    by 0x1A181E: nmp_utils_ethtool_supports_vlans (nm-platform-utils.c:912)
==6207==    by 0x1756D7: link_supports_vlans (nm-linux-platform.c:6508)
==6207==    by 0x1A81D8: nm_platform_link_supports_vlans (nm-platform.c:1536)
==6207==    by 0x14B96B: test_internal (test-link.c:602)
==6207==    by 0x4F5C18D: test_case_run (gtestutils.c:2597)
==6207==    by 0x4F5C18D: g_test_run_suite_internal (gtestutils.c:2685)
==6207==    by 0x4F5BF33: g_test_run_suite_internal (gtestutils.c:2697)
==6207==    by 0x4F5C679: g_test_run_suite (gtestutils.c:2772)
==6207==    by 0x4F5C694: g_test_run (gtestutils.c:2007)
==6207==    by 0x166B4D: main (test-common.c:2092)
==6207==  Address 0x1ffeffeecf is on thread 1's stack
==6207==  in frame #1, created by _ioctl_call (nm-platform-utils.c:110)
==6207==

"ifname" is the stack-allocated array "known_ifnames" of suitable
IFNAMSIZ bytes. But it may not be fully initialized, so using memcpy()
to copy the string leads to unintialized warning.

We really should only copy the valid bytes, either with strcpy() or our
nm_utils_ifname_cpy() wrapper.

Fixes: 856322562eff ('platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii')

"struct ifreq" contains a union field, and initalizing the struct is not
guaranteed to fill all bytes with zero (it only sets the first union
member to zero).

Since we later return the entire struct, ensure that it's initialized to
all zero by using memset().

ethtool/mii API is based on the ifname. As an interface can be renamed,
this API is inherently racy. We would prefer to use the ifindex instead.
The ifindex of a device cannot change (altough it can repeat, which opens a
different race *sigh*).

Anyway, we were already trying to minimize the race be resolving the
name from ifindex immediately before the call to ethtool/mii.

Do better than that. Now resolve the name before and after the call. If
the name changed in the meantime, we have an indication that a race
might have happend (but we cannot be sure).

Note that this can not catch every possible kind of rename race. If you are very
unlucky a swapping of names cannot be detected.

For getters this is relatively straight forward. Just retry when we
have an indication to fall victim to a race (up to a few times). Yes, we
still cannot be 100% sure, but this should be very reliable in practice.

For setters (that modify the device) we also retry. We do so under the
assumption that setting the same options multiple times has no bad effect.
Note that for setters the race of swapping interface names is particularly
bad. If we hit a very unlucky race condition, we might set the setting on
the wrong interface and there is nothing we can do about it. The retry only
ensures that eventually we will set it on the right interface.

Note that this involves one more if_indextoname() call for each operation (in
the common case when there is no renaming race). In cases where we make
multiple ioctl calls, we cache and reuse the information though. So, for such
calls the overhead is even smaller.

"libnm-core" implements common functionality for "NetworkManager" and
"libnm".

Note that clients like "nmcli" cannot access the internal API provided
by "libnm-core". So, if nmcli wants to do something that is also done by
"libnm-core", , "libnm", or "NetworkManager", the code would have to be
duplicated.

Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
Note that:

  0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
     On the other hand, "libnm-libnm-core-aux.la" is not used by
     libnm-core, but provides utilities on top of it.

  1) they both extend "libnm-core" with utlities that are not public
     API of libnm itself. Maybe part of the code should one day become
     public API of libnm. On the other hand, this is code for which
     we may not want to commit to a stable interface or which we
     don't want to provide as part of the API.

  2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
     and thus directly available to "libnm" and "NetworkManager".
     On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
     and "NetworkManager".
     Both libraries may be statically linked by libnm clients (like
     nmcli).

  3) it must only use glib, libnm-glib-aux.la, and the public API
     of libnm-core.
     This is important: it must not use "libnm-core/nm-core-internal.h"
     nor "libnm-core/nm-utils-private.h" so the static library is usable
     by nmcli which couldn't access these.

Note that "shared/nm-meta-setting.c" is an entirely different case,
because it behaves differently depending on whether linking against
"libnm-core" or the client programs. As such, this file must be compiled
twice.

(cherry picked from commit af07ed01c04867e281cc3982a7ab0d244d4f8e2e)

Use the NM_ERRNO_NATIVE() macro that asserts that these errno numbers are
indeed positive. Using the macro also serves as a documentation of what
the meaning of these numbers is.

That is often not obvious, whether we have an nm_errno(), an nm_errno_native()
(from <errno.h>), or another error number (e.g. WaitForNlResponseResult). This
situation already improved by merging netlink error codes (nle),
NMPlatformError enum and <errno.h> as nm_errno(). But we still must
always be careful about not to mix error codes from different
domains or transform them appropriately (like nm_errno_from_native()).