<gmodule.h> is implicitly included by <gio/gio.h> which is available
everywhere. For that reason, we would not have to include this header
at all. However, it is recommended to explicitly include <gmodule.h>
where needed.
So, include it where needed -- if <gio/gio.h> wouldn't be there --
and drop it from where it is not needed.
When a new dynamic configuration is received, it is stored in a member
of private structure (e.g. @dhcp6_ip6_config) and a commit is
scheduled. Before the commit is executed, an update_ipx_config() could
be called and it would change the configuration before it is
committed.
This race condition causes failures in assigning the addresses
received through DHCPv6 when the internal client is used (but
potentially other clients and methods are affected).
To fix it, postpone updates of IP configurations when a commit is
already pending.
Closing the library will interfere badly as the glib types cannot be
unregistered. We must leak the library handle.
Switch to dlopen() instead of g_module_open(), because the former
supports RTLD_NOLOAD. This is useful for two reasons:
- checking the file prior loading only makes any sense when
dlopen() would actually load a file anew.
- if the library was loaded before, we want to return the handle.
On the other hand, if the library was not loaded, we leak the
handle.
Thereby, refactor the code from if-else blocks to return-early, because
the function nicely does individual steps and if one fails just error
out.
On s390 size_t is an unsigned long, not an unsigned int. They both are
of the same size and can be cast to each other safely, but the compiler
still seems unhappy about incompatible pointers.
https://github.com/systemd/systemd/pull/3147
It can return NULL and makes Coverity upset:
CID 75369 (#1 of 1): Dereference null return value (NULL_RETURNS)
4. dereference: Dereferencing a null pointer ret.
It is recomended to include <config.h> with angle brackets [1].
Note, that usually we don't include <config.h> directly, except in
two places we have to (because there we include conflicting libraries
that must be included before "nm-default.h").
In that case, define __CONFIG_H__ which is used as include guard around
<config.h> by "nm-default.h".
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Configuration-Headers.html
g_object_get_data() and g_object_get_qdata() end up to be identical,
except that g_object_get_data() also requires to intern the string
on every lookup (which involves a hash lookup and locking).
For a type to be inheritable, its public struct (NMManager) must
be known. As nobody inherits NMManager, we can make it private.
As the struct is private anyway, we can also reuse it for the private
data directly, instead of registering NMManagerPrivate in the manager
class.
There are advantages and disadvantages:
+ simplifies debugging, as the self pointer also contains the
private data.
+ removes a small overhead of tracking the private data separately
- is a different way to implement the class, contrary to many
other classes.
- inheriting from the class later requires reverting this change
(but we will never inherit from NMManager).
- as it is now, nobody uses the priv field directly and we still
access it via NM_MANAGER_GET_PRIVATE(self). However, the presence
of the priv field might encourage us to use it directly -- which
increases above disadvantages.
The only user of the sleep-monitor singleton was NMManager anyway.
Also, even if we ever get more users that are interested in the SLEEPING
signal, we would hook them onto NMManager -- because NMManager should
collect, coordinate and possibly forward the SLEEPING signal. In no case,
another object should react on the SLEEPING signal and thus bypassing the
NMManager.
Both files do very similar things, with "nm-sleep-monitor-upower.c"
being suboptimal, for example by creating the proxy synchronously.
Clean that up in the next steps. Just basic merging for now.
..., nm_platform_ip6_route_cmp(), nm_platform_ip4_address_cmp() and
nm_platform_ip6_address_cmp().
Compare those fields first, for which we expect that their properties
differ. E.g. usually, each route destination in a set is unique, thus by
comparing those fields first we shortcut some comparisons.
For addresses (NMPlatformIPAddress) the @addr_source field is ignored
on a platform level. That is, all addresses inside the platform cache
have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason,
the source should not be a part of the NMPlatformIPAddress structure, but
it is convenient for users to piggy back the source inside the platform
address structure.
For routes, the source is stored in NMPlatformIPRoute's @rt_source
field. When adding a route to kernel, we set the @rtm_protocol of the
route depending on the source. However, we want to map different source
values to the same protocol value.
On the other hand, when kernel sends us a route that gets put inside
the cache, we must preserve the protocol value and must not map
different protocol values to the same source.
The reason is, that a user can add two routes that only differ by
@rtm_protocol. In that sense, the @rtm_protocol fields is part of the
unique ID of a kernel route, and thus different values must map to
different sources.
Fix this, by extending the range of NMIPConfigSource to contain
a range of protocol fields.
We handle cloned routes (that have rtm_flags RTM_F_CLONED) differently.
We used to mark such routes by hacking NMIPConfigSource to have a special
value. No longer do this, because it mixes different concepts.
Note that the rt_cloned filed fits into a hole in the aligment
of NMPlatformIPRoute. Thus there is almost no overhead to this
change.
The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
protocol field of the route. The source of NMPlatformIPAddress (now
"addr_source") has no direct equivalent in the kernel.
As their use is different, they should have different names. Also,
the name "source" is used all over the place. Hence give the fields
a more distinct name.
This way, we get a defined order at startup.
Also, get rid of the logging statements. It was used for
debugging, but a "getter" really should not log the stuff it
is returning.
When performing NM package upgrade the new version of nmcli will be immediately
available while NM daemon will not, as it would not restart in order to avoid
to disrupt connectivity. This could create issues with tools leveraging
on nmcli output (till reboot). As apart from this case it is very unlikely
that a user can have this nmcli / NM daemon version mismatch situation,
the check could cause more harm than benefit in real user case
scenarios.
https://bugzilla.redhat.com/show_bug.cgi?id=1291785
The 'portname' sysfs attribute of s390 devices is deprecated since
kernel 4.4 and always set to 'no portname required'. But even on older
kernels such value must be interpreted as an unset portname and thus
ignored.
https://bugzilla.redhat.com/show_bug.cgi?id=1327204
Having a gateway defined when never-default=yes causes troubles in
connection matching and anyway makes no sense.
If the combination is found, remove the gateway during the
normalization phase.
https://bugzilla.redhat.com/show_bug.cgi?id=1313091
