Strangely, this breaks
systemctl restart NetworkManager
nmcli connection up "$NAME"
It seems that with this change, libnm misses some events from D-Bus.
It looks like there is something seriously broken. Before fixing it,
revert the previous state.
https://bugzilla.redhat.com/show_bug.cgi?id=1450075
This reverts commit 529d620a59.
(cherry picked from commit 45d6147098)
These properties are internal and shall not be publicly accessible.
Remove the getter.
We may later no longer use GDBusObjectManager. It should be an implementation
detail, not exposed in the public API of NMObject.
(cherry picked from commit 357fd6ba82)
The current implementation of GDBusObjectManagerClient implements
GAsyncInitableIface, however it simply runs GInitableIface's
synchronous init on another thread.
I suspect that there are races in the way that is implemented.
For one, we see crashes and warnings (rh#1450075, rh#1457769,
rh#1457223). Also, it seems very wrong to me, how GDBusObjectManagerClient
mixes asynchronous signals (on_control_proxy_g_signal) with
synchronously getting all objects (process_get_all_result,
GetManagedObjects).
I think we should ditch GDBusObjectManager altogether, including the
gdbus-codegen skeletons. They add layers of code, for something that
should be simple to do directly. For now, just don't do asynchronous
initialization on another thread, so we at least avoid this kind of
multithreadding issue.
This may make the initialization of NMClient a bit slower.
(cherry picked from commit 529d620a59)
Cancelling an operation shall not mean to not invoke the result callback.
The result callback is *always* to be invoked.
(cherry picked from commit c5a48b7a0b)
Previously, internal parts of libnm were not testable.
Instead, add "libnm/nm-libnm-utils.c" and "libnm/libnm-utils.la"
to contain code that can be statically linked with a new
test "libnm/tests/test-general".
(cherry picked from commit 8df944c7e4)
No need to create a separate NMUdevClient instance for all devices.
Instead, have one "struct udev" instance in NMClient and pass
it down during object construction.
state_changed_proxy() updates the value of @state and must also emit
the notify signal for it.
Without this, when the PropertiesChanged signal carrying the change of
'state' arrives after StateChanged, we notice that the value of @state
doesn't change and don't emit the notify, causing a loss of the state
change event.
Fixes: 40ffb962behttps://bugzilla.redhat.com/show_bug.cgi?id=1433883
NMVpnConnectionStateReason is no longer used and replaced by
NMActiveConnectionStateReason. However, the old enums should
stay in place as they were:
Otherwise:
#define NMVpnConnectionStateReason NMActiveConnectionStateReason
causes compiler warnings:
NMVpnConnectionStateReason x;
x = NM_VPN_CONNECTION_STATE_REASON_UNKNOWN; // -Wenum-conversion
if (x == NM_VPN_CONNECTION_STATE_REASON_NO_SECRETS) { } // -Wenum-compare
Similarly, a user who didn't upgrade shall continue to get the
old GType for NM_TYPE_VPN_CONNECTION_STATE_REASON.
In practice, old users will have no issues using the old enum
the places where it worked before.
The only use of the deprecated enum is in vpn_state_changed()
signal slot of NMVpnConnection. This makes the signal slot
itself deprecated. However, NMVpnConnection is an NMObject and commonly
created within libnm itself, not by the user. It is very unlikely that
a user of libnm subclassed NMVpnConnection and makes use of the
vpn_state_changed() signal slot. So, deprecate it without replacement.
Fixes: a91369f80d
Note that the reason tracking starts as soon as the object exists (which
is immediately after GDBusObject is created), not when the asynchronous
NMObject initialization finishes. That is so that we the reason changes
in between are not lost.
The vpn-connection should probably be doing the same.
It includes a reason code that makes it possible for the clients to be
more reasonable about error messages.
The reason code is essentially copied from the VPN, plus three more
reasons that were useful for non-VPN connections.
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
The libnm cache types don't have public _new() functions.
However, such types can be easily created using g_object_new()
directly from user code.
Such a usage is not supported. Add an assertion that a valid
dbus-object is present.
This adds definition of a set of known route option attributes to
libnm-core and helper functions.
nm_ip_route_attribute_validate() performs the validation of the
attribute type and, in case of a formatted string attribute, of its
content.
nm_ip_route_get_variant_attribute_spec() returns the attribute format
specifier to be passed to nm_utils_parse_variant_attributes(). Since
at the moment NMIPRoute is the only user of NMVariantAttributeSpec and
the type is opaque to users of the library, the struct is extended to
carry some other data useful for validation.
Various libnm objects (addresses, routes) carry an hash table of
attributes represented as GVariants indexed by name. Add common
routines to convert to and from a string representation.
To parse a string, a knowledge of the supported attributes (and their
types) is needed: we represent it as an opaque type
NMVariantAttributeSpec that callers must query to the library for the
specific object type and pass to the parse function.
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
