fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-23 10:50:06 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/libnm/nm-client.c

4442 lines
147 KiB
C
Raw Normal View History

all: SPDX header conversion $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
2019-09-10 11:19:01 +02:00
// SPDX-License-Identifier: LGPL-2.1+
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2007 - 2008 Novell, Inc.
* Copyright (C) 2007 - 2018 Red Hat, Inc.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
#include "nm-default.h"
all: consistently include config.h config.h should be included from every .c file, and it should be included before any other include. Fix that. (As a side effect of how I did this, this also changes us to consistently use "config.h" rather than <config.h>. To the extent that it matters [which is not much], quotes are more correct anyway, since we're talking about a file in our own build tree, not a system include.)
2014-11-13 10:07:02 -05:00
all: drop unnecessary includes of <errno.h> and <string.h> "nm-macros-interal.h" already includes <errno.h> and <string.h>. No need to include it everywhere else too.
2019-01-31 13:44:13 +01:00
#include "nm-client.h"
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
#include <libudev.h>
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement nm_client_deactivate_connection_async() by using GDBusConnection directly
2019-10-02 13:38:36 +02:00
#include "nm-glib-aux/nm-dbus-aux.h"
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
#include "nm-utils.h"
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
#include "nm-manager.h"
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
#include "nm-dns-manager.h"
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
#include "nm-remote-settings.h"
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
#include "nm-device-ethernet.h"
#include "nm-device-wifi.h"
libnm: drop NM_TYPE_OBJECT_ARRAY, use G_TYPE_PTR_ARRAY Use G_TYPE_PTR_ARRAY for GPtrArray-of-NMObject-valued properties, because it has better introspection/bindings support. As with the strdict change in libnm-core, we need to manually copy the array in get_property() implementations, to preserve the standard semantics that get_property() returns a copy, not the internal array. (This patch also changes those properties so that they are always non-NULL until dispose(); previously some of them could be either NULL or 0-length at different times.)
2014-08-26 08:31:04 -04:00
#include "nm-core-internal.h"
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
#include "nm-active-connection.h"
#include "nm-vpn-connection.h"
libnm: add nm-types.h, to avoid include loops Add nm-types.h defining all the type structs, to avoid future include loops. Clean up the includes in all of the installed headers.
2014-10-09 09:12:42 -04:00
#include "nm-remote-connection.h"
libnm: port to GDBus Port libnm-core/libnm to GDBus. The NetworkManager daemon continues to use dbus-glib; the previously-added connection hash/variant conversion methods are now moved to NetworkManagerUtils (along with a few other utilities that are now only needed by the daemon code).
2014-09-10 13:51:53 -04:00
#include "nm-dbus-helpers.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-wimax-nsp.h"
#include "nm-object-private.h"
all: rename the introspection data to use the interface paths in names This makes it easier to install the files with proper names. Also, it makes the makefile rules slightly simpler. Lastly, the documentation is now generated into docs/api, which makes it possible to get rid of the awkward relative file names in docbook.
2016-11-23 13:14:08 +01:00
#include "introspection/org.freedesktop.NetworkManager.h"
#include "introspection/org.freedesktop.NetworkManager.Device.Wireless.h"
wifi-p2p: rename Wi-Fi P2P After renaming the files, also rename all the content to follow the "Wi-Fi P2P" naming scheme.
2019-01-28 15:21:59 +01:00
#include "introspection/org.freedesktop.NetworkManager.Device.WifiP2P.h"
all: rename the introspection data to use the interface paths in names This makes it easier to install the files with proper names. Also, it makes the makefile rules slightly simpler. Lastly, the documentation is now generated into docs/api, which makes it possible to get rid of the awkward relative file names in docbook.
2016-11-23 13:14:08 +01:00
#include "introspection/org.freedesktop.NetworkManager.Device.h"
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
#include "introspection/org.freedesktop.NetworkManager.DnsManager.h"
all: rename the introspection data to use the interface paths in names This makes it easier to install the files with proper names. Also, it makes the makefile rules slightly simpler. Lastly, the documentation is now generated into docs/api, which makes it possible to get rid of the awkward relative file names in docbook.
2016-11-23 13:14:08 +01:00
#include "introspection/org.freedesktop.NetworkManager.Settings.h"
#include "introspection/org.freedesktop.NetworkManager.Settings.Connection.h"
#include "introspection/org.freedesktop.NetworkManager.VPN.Connection.h"
libnm/active-connection: track reason for state changes 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.
2017-03-05 17:20:27 +01:00
#include "introspection/org.freedesktop.NetworkManager.Connection.Active.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-access-point.h"
#include "nm-active-connection.h"
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
#include "nm-checkpoint.h"
libnm: add support form 6LoWPAN devices
2018-05-22 16:45:05 +02:00
#include "nm-device-6lowpan.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-device-adsl.h"
#include "nm-device-bond.h"
#include "nm-device-bridge.h"
#include "nm-device-bt.h"
core: add support for dummy devices 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.
2017-01-31 14:14:33 +01:00
#include "nm-device-dummy.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-device-ethernet.h"
#include "nm-device-generic.h"
#include "nm-device-infiniband.h"
#include "nm-device-ip-tunnel.h"
core,libnm: introduce NMDeviceMacsec At the moment the device only exposes the current link status, but cannot create new links.
2016-06-30 18:20:22 +02:00
#include "nm-device-macsec.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-device-macvlan.h"
#include "nm-device-modem.h"
#include "nm-device-olpc-mesh.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-device-ovs-bridge.h"
libnm: add support for ovs-interface devices
2017-10-10 11:04:32 +02:00
#include "nm-device-ovs-interface.h"
libnm: add support for ovs-port devices
2017-10-10 11:04:32 +02:00
#include "nm-device-ovs-port.h"
device: add NMDevicePPP The new device type represents a PPP interface, and will implement the activation of new-style PPPoE connections, i.e. the ones that don't claim the parent device.
2017-06-06 15:55:08 +02:00
#include "nm-device-ppp.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-device-team.h"
#include "nm-device-tun.h"
#include "nm-device-vlan.h"
#include "nm-device-vxlan.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-device-wifi-p2p.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-device-wifi.h"
#include "nm-device-wimax.h"
libnm: introduce NMDeviceWireGuard
2018-03-13 13:42:38 +00:00
#include "nm-device-wireguard.h"
libnm: add support for WPAN devices
2018-03-09 17:19:36 +01:00
#include "nm-device-wpan.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-dhcp-config.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-dhcp4-config.h"
#include "nm-dhcp6-config.h"
#include "nm-ip4-config.h"
#include "nm-ip6-config.h"
#include "nm-manager.h"
wifi-p2p: rename files for consistent Wi-Fi P2P naming We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
2019-01-28 12:39:38 +01:00
#include "nm-wifi-p2p-peer.h"
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
#include "nm-remote-connection.h"
#include "nm-remote-settings.h"
#include "nm-vpn-connection.h"
libnm: port to GDBus Port libnm-core/libnm to GDBus. The NetworkManager daemon continues to use dbus-glib; the previously-added connection hash/variant conversion methods are now moved to NetworkManagerUtils (along with a few other utilities that are now only needed by the daemon code).
2014-09-10 13:51:53 -04:00
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void nm_client_initable_iface_init (GInitableIface *iface);
static void nm_client_async_initable_iface_init (GAsyncInitableIface *iface);
libnm/trivial: move code
2017-06-21 15:17:31 +02:00
typedef struct {
NMClient *client;
GCancellable *cancellable;
GSimpleAsyncResult *result;
int pending_init;
} NMClientInitData;
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
NM_GOBJECT_PROPERTIES_DEFINE (NMClient,
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
PROP_DBUS_CONNECTION,
libnm: add NM_CLIENT_DBUS_NAME_OWNER property It's not yet implemented. But obviously it's interesting to get the name owner to which the NMClient is currently connected. Note only that: the name-owner property really says whether NM is currently running or not.
2019-10-15 16:08:36 +02:00
PROP_DBUS_NAME_OWNER,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
PROP_VERSION,
PROP_STATE,
PROP_STARTUP,
libnm: synchronize NMClient and NMRemoteSettings "is NM running" properties Rename NMClient:manager-running and NMRemoteSettings:service-running to both be :nm-running.
2014-08-05 10:05:26 -04:00
PROP_NM_RUNNING,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
PROP_NETWORKING_ENABLED,
PROP_WIRELESS_ENABLED,
PROP_WIRELESS_HARDWARE_ENABLED,
PROP_WWAN_ENABLED,
PROP_WWAN_HARDWARE_ENABLED,
PROP_WIMAX_ENABLED,
PROP_WIMAX_HARDWARE_ENABLED,
PROP_ACTIVE_CONNECTIONS,
PROP_CONNECTIVITY,
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
PROP_CONNECTIVITY_CHECK_AVAILABLE,
PROP_CONNECTIVITY_CHECK_ENABLED,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
PROP_PRIMARY_CONNECTION,
PROP_ACTIVATING_CONNECTION,
PROP_DEVICES,
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
PROP_ALL_DEVICES,
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
PROP_CONNECTIONS,
PROP_HOSTNAME,
PROP_CAN_MODIFY,
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
PROP_METERED,
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
PROP_DNS_MODE,
PROP_DNS_RC_MANAGER,
PROP_DNS_CONFIGURATION,
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
PROP_CHECKPOINTS,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
enum {
DEVICE_ADDED,
DEVICE_REMOVED,
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
ANY_DEVICE_ADDED,
ANY_DEVICE_REMOVED,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
PERMISSION_CHANGED,
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
CONNECTION_ADDED,
CONNECTION_REMOVED,
libnm/client: emit signals when active connection disappears It allows us to reliably track failures to activate a connection.
2016-07-07 11:35:19 +02:00
ACTIVE_CONNECTION_ADDED,
ACTIVE_CONNECTION_REMOVED,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
LAST_SIGNAL
};
static guint signals[LAST_SIGNAL] = { 0 };
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
typedef struct {
libnm: remember the caller's GMainContext when creating NMClient We will require this later. The NMClient shall be tied to the GMainContext at the moment when the instance gets created. This allows the user to have multiple, indendent NMClient instances (on different threads and GMainContext). Currently this is still unused, it will be later.
2019-10-12 14:17:16 +02:00
GMainContext *main_context;
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
NMManager *manager;
NMRemoteSettings *settings;
NMDnsManager *dns_manager;
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
GDBusConnection *dbus_connection;
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
GDBusObjectManager *object_manager;
GCancellable *new_object_manager_cancellable;
char *name_owner_cached;
struct udev *udev;
bool udev_inited:1;
} NMClientPrivate;
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
struct _NMClient {
GObject parent;
NMClientPrivate _priv;
};
struct _NMClientClass {
GObjectClass parent;
};
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
G_DEFINE_TYPE_WITH_CODE (NMClient, nm_client, G_TYPE_OBJECT,
G_IMPLEMENT_INTERFACE (G_TYPE_INITABLE, nm_client_initable_iface_init);
G_IMPLEMENT_INTERFACE (G_TYPE_ASYNC_INITABLE, nm_client_async_initable_iface_init);
)
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
#define NM_CLIENT_GET_PRIVATE(self) _NM_GET_PRIVATE(self, NMClient, NM_IS_CLIENT)
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
/*****************************************************************************/
void _nm_device_wifi_set_wireless_enabled (NMDeviceWifi *device, gboolean enabled);
/*****************************************************************************/
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
static const GPtrArray empty = { 0, };
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* nm_client_error_quark:
*
* Registers an error quark for #NMClient if necessary.
*
* Returns: the error quark used for #NMClient errors.
**/
all: use NM_CACHED_QUARK_FCN() to define cached quarks
2017-02-03 17:21:21 +01:00
NM_CACHED_QUARK_FCN ("nm-client-error-quark", nm_client_error_quark)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: add helper functions for refactoring D-Bus calls in libnm We will drop GDBusProxy and the gdbus-codegen classes. First, we need to replace all D-Bus calls from nmdbus_*() API with plain uses of GDBusConnection. For that, add accessors to get the dbus-connection and the name-owner. This API is not beautiful, it's an interim solution for now.
2019-10-04 13:56:36 +02:00
GDBusConnection *
_nm_client_get_dbus_connection (NMClient *client)
{
nm_assert (NM_IS_CLIENT (client));
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
return NM_CLIENT_GET_PRIVATE (client)->dbus_connection;
libnm: add helper functions for refactoring D-Bus calls in libnm We will drop GDBusProxy and the gdbus-codegen classes. First, we need to replace all D-Bus calls from nmdbus_*() API with plain uses of GDBusConnection. For that, add accessors to get the dbus-connection and the name-owner. This API is not beautiful, it's an interim solution for now.
2019-10-04 13:56:36 +02:00
}
const char *
_nm_client_get_dbus_name_owner (NMClient *client)
{
NMClientPrivate *priv;
nm_assert (NM_IS_CLIENT (client));
priv = NM_CLIENT_GET_PRIVATE (client);
nm_clear_g_free (&priv->name_owner_cached);
if (!priv->object_manager)
return NULL;
priv->name_owner_cached = g_dbus_object_manager_client_get_name_owner (G_DBUS_OBJECT_MANAGER_CLIENT (priv->object_manager));
return priv->name_owner_cached;
}
/*****************************************************************************/
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
static gboolean
_nm_client_check_nm_running (NMClient *client, GError **error)
{
libnm: add helper functions for refactoring D-Bus calls in libnm We will drop GDBusProxy and the gdbus-codegen classes. First, we need to replace all D-Bus calls from nmdbus_*() API with plain uses of GDBusConnection. For that, add accessors to get the dbus-connection and the name-owner. This API is not beautiful, it's an interim solution for now.
2019-10-04 13:56:36 +02:00
if (!nm_client_get_nm_running (client)) {
_nm_object_set_error_nm_not_running (error);
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
return FALSE;
}
libnm: add helper functions for refactoring D-Bus calls in libnm We will drop GDBusProxy and the gdbus-codegen classes. First, we need to replace all D-Bus calls from nmdbus_*() API with plain uses of GDBusConnection. For that, add accessors to get the dbus-connection and the name-owner. This API is not beautiful, it's an interim solution for now.
2019-10-04 13:56:36 +02:00
return TRUE;
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
}
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
/**
* nm_client_get_dbus_connection:
* @client: a #NMClient
*
* Gets the %GDBusConnection of the instance. This can be either passed when
* constructing the instance (as "dbus-connection" property), or it will be
* automatically initialized during async/sync init.
*
* Returns: (transfer none): the D-Bus connection of the client, or %NULL if none is set.
*
* Since: 1.22
**/
GDBusConnection *
nm_client_get_dbus_connection (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
return NM_CLIENT_GET_PRIVATE (client)->dbus_connection;
}
libnm: add NM_CLIENT_DBUS_NAME_OWNER property It's not yet implemented. But obviously it's interesting to get the name owner to which the NMClient is currently connected. Note only that: the name-owner property really says whether NM is currently running or not.
2019-10-15 16:08:36 +02:00
/**
* nm_client_get_dbus_name_owner:
* @client: a #NMClient
*
* Returns: (transfer none): the current name owner of the D-Bus service of NetworkManager.
*
* Since: 1.22
**/
const char *
nm_client_get_dbus_name_owner (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
/* FIXME(release-blocker): not yet implemented. */
return NULL;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_version:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets NetworkManager version.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
* Returns: string with the version (or %NULL if NetworkManager is not running)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
const char *
nm_client_get_version (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NULL;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_version (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_state:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets the current daemon state.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: the current %NMState
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
NMState
nm_client_get_state (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NM_STATE_UNKNOWN);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NM_STATE_UNKNOWN;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_state (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_startup:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Tests whether the daemon is still in the process of activating
* connections at startup.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: whether the daemon is still starting up
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
gboolean
nm_client_get_startup (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_startup (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
/**
* nm_client_get_nm_running:
* @client: a #NMClient
*
* Determines whether the daemon is running.
*
* Returns: %TRUE if the daemon is running
**/
gboolean
nm_client_get_nm_running (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
return NM_CLIENT_GET_PRIVATE (client)->manager != NULL;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
/**
* nm_client_networking_get_enabled:
* @client: a #NMClient
*
* Whether networking is enabled or disabled.
*
* Returns: %TRUE if networking is enabled, %FALSE if networking is disabled
**/
gboolean
nm_client_networking_get_enabled (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_networking_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
/**
* nm_client_networking_set_enabled:
* @client: a #NMClient
* @enabled: %TRUE to set networking enabled, %FALSE to set networking disabled
* @error: (allow-none): return location for a #GError, or %NULL
*
* Enables or disables networking. When networking is disabled, all controlled
* interfaces are disconnected and deactivated. When networking is enabled,
* all controlled interfaces are available for activation.
*
* Returns: %TRUE on success, %FALSE otherwise
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_networking_set_enabled_async() or GDBusConnection
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
**/
gboolean
nm_client_networking_set_enabled (NMClient *client, gboolean enable, GError **error)
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
{
libnm: implement nm_client_networking_set_enabled() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
const char *name_owner;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
/* FIXME(libnm-async-api): add nm_client_networking_set_enabled_async(). */
libnm: implement nm_client_networking_set_enabled() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
name_owner = _nm_client_get_dbus_name_owner (client);
if (!name_owner) {
_nm_object_set_error_nm_not_running (error);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
return FALSE;
libnm: implement nm_client_networking_set_enabled() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
}
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: implement nm_client_networking_set_enabled() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
return _nm_manager_networking_set_enabled (_nm_client_get_dbus_connection (client),
name_owner,
enable,
error);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
/**
* nm_client_wireless_get_enabled:
* @client: a #NMClient
*
* Determines whether the wireless is enabled.
*
* Returns: %TRUE if wireless is enabled
**/
gboolean
nm_client_wireless_get_enabled (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_wireless_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wireless_set_enabled:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @enabled: %TRUE to enable wireless
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Enables or disables wireless devices.
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_wireless_set_enabled_async() or GDBusConnection
*/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
void
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_wireless_set_enabled (NMClient *client, gboolean enabled)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
/* FIXME(libnm-async-api): add nm_client_wireless_set_enabled_async(). */
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
return;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
nm_manager_wireless_set_enabled (NM_CLIENT_GET_PRIVATE (client)->manager, enabled);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wireless_hardware_get_enabled:
* @client: a #NMClient
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Determines whether the wireless hardware is enabled.
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: %TRUE if the wireless hardware is enabled
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
gboolean
nm_client_wireless_hardware_get_enabled (NMClient *client)
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_wireless_hardware_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
/**
* nm_client_wwan_get_enabled:
* @client: a #NMClient
*
* Determines whether WWAN is enabled.
*
* Returns: %TRUE if WWAN is enabled
**/
gboolean
nm_client_wwan_get_enabled (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_wwan_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wwan_set_enabled:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @enabled: %TRUE to enable WWAN
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Enables or disables WWAN devices.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
void
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_wwan_set_enabled (NMClient *client, gboolean enabled)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
if (!_nm_client_check_nm_running (client, NULL))
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
return;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
nm_manager_wwan_set_enabled (NM_CLIENT_GET_PRIVATE (client)->manager, enabled);
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wwan_hardware_get_enabled:
* @client: a #NMClient
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Determines whether the WWAN hardware is enabled.
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: %TRUE if the WWAN hardware is enabled
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
gboolean
nm_client_wwan_hardware_get_enabled (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_wwan_hardware_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wimax_get_enabled:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Determines whether WiMAX is enabled.
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: %TRUE if WiMAX is enabled
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
gboolean
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_wimax_get_enabled (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: make sync/async APIs more GLib-like Make synchronous APIs take GCancellables, and make asynchronous APIs use GAsyncReadyCallbacks and have names ending in "_async", with "_finish" functions to retrieve the results. Also, make nm_client_activate_connection_finish(), nm_client_add_and_activate_finish(), and nm_remote_settings_add_connection_finish() be (transfer full) rather than (transfer none), because the refcounting semantics become slightly confusing in some edge cases otherwise.
2014-09-11 16:27:13 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_wimax_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wimax_set_enabled:
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @enabled: %TRUE to enable WiMAX
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Enables or disables WiMAX devices.
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
**/
void
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_wimax_set_enabled (NMClient *client, gboolean enabled)
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
return;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
nm_manager_wimax_set_enabled (NM_CLIENT_GET_PRIVATE (client)->manager, enabled);
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_wimax_hardware_get_enabled:
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Determines whether the WiMAX hardware is enabled.
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: %TRUE if the WiMAX hardware is enabled
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
**/
gboolean
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_wimax_hardware_get_enabled (NMClient *client)
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return FALSE;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_wimax_hardware_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add some missing sync/async method variants Add the missing variant in most places in the API where previously there was either only a synchronous version or only an asynchronous version. There is not yet a synchronous nm_client_activate_connection(), nm_client_add_and_activate_connection(), or nm_remote_settings_add_connection(), because the existing async code depends on waiting for other asynchronous events, so making them run synchronously is slightly more complicated. But these APIs can be added later.
2014-09-11 16:27:13 -04:00
}
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
/**
* nm_client_connectivity_check_get_available:
* @client: a #NMClient
*
* Determine whether connectivity checking is available. This
* requires that the URI of a connectivity service has been set in the
* configuration file.
*
* Returns: %TRUE if connectivity checking is available.
libnm: add gtk-doc Since markers for new API and missing enum documentation
2017-08-17 23:08:44 +02:00
*
* Since: 1.10
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
*/
gboolean
nm_client_connectivity_check_get_available (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
if (!nm_client_get_nm_running (client))
return FALSE;
return nm_manager_connectivity_check_get_available (NM_CLIENT_GET_PRIVATE (client)->manager);
}
/**
* nm_client_connectivity_check_get_enabled:
* @client: a #NMClient
*
* Determine whether connectivity checking is enabled.
*
* Returns: %TRUE if connectivity checking is enabled.
libnm: add gtk-doc Since markers for new API and missing enum documentation
2017-08-17 23:08:44 +02:00
*
* Since: 1.10
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
*/
gboolean
nm_client_connectivity_check_get_enabled (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
if (!nm_client_get_nm_running (client))
return FALSE;
return nm_manager_connectivity_check_get_enabled (NM_CLIENT_GET_PRIVATE (client)->manager);
}
/**
* nm_client_connectivity_check_set_enabled:
* @client: a #NMClient
* @enabled: %TRUE to enable connectivity checking
*
* Enable or disable connectivity checking. Note that if a
* connectivity checking URI has not been configured, this will not
* have any effect.
libnm: add gtk-doc Since markers for new API and missing enum documentation
2017-08-17 23:08:44 +02:00
*
* Since: 1.10
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
*/
void
nm_client_connectivity_check_set_enabled (NMClient *client, gboolean enabled)
{
g_return_if_fail (NM_IS_CLIENT (client));
if (!nm_client_get_nm_running (client))
return;
nm_manager_connectivity_check_set_enabled (NM_CLIENT_GET_PRIVATE (client)->manager, enabled);
}
libnm,core: Add ConnectivityCheckUri property and accessors So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
2019-07-22 15:55:15 +01:00
/**
* nm_client_connectivity_check_get_uri:
* @client: a #NMClient
*
* Get the URI that will be queried to determine if there is internet
* connectivity.
*
* Returns: (transfer none): the connectivity URI in use
*
* Since: 1.20
*/
const char *
nm_client_connectivity_check_get_uri (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
if (!nm_client_get_nm_running (client))
return NULL;
return nm_manager_connectivity_check_get_uri (NM_CLIENT_GET_PRIVATE (client)->manager);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_logging:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @level: (allow-none): return location for logging level string
* @domains: (allow-none): return location for log domains string. The string is
* a list of domains separated by ","
* @error: (allow-none): return location for a #GError, or %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets NetworkManager current logging level and domains.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: %TRUE on success, %FALSE otherwise
libnm: mark more synchronous libnm API as deprecated This is a follow-up to commit e90684a169a7 ('libnm: deprecate synchronous/blocking API in libnm') to mark more of such synchronous API as deprecated.
2019-10-04 16:48:39 +02:00
*
* Deprecated: 1.22, use nm_client_get_logging_async() or GDBusConnection
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
gboolean
libnm: implement nm_client_get_logging()/nm_client_set_logging() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
nm_client_get_logging (NMClient *client,
char **level,
char **domains,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_get_logging()/nm_client_set_logging() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
gs_unref_variant GVariant *ret = NULL;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
g_return_val_if_fail (level == NULL || *level == NULL, FALSE);
g_return_val_if_fail (domains == NULL || *domains == NULL, FALSE);
g_return_val_if_fail (error == NULL || *error == NULL, FALSE);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: mark more synchronous libnm API as deprecated This is a follow-up to commit e90684a169a7 ('libnm: deprecate synchronous/blocking API in libnm') to mark more of such synchronous API as deprecated.
2019-10-04 16:48:39 +02:00
/* FIXME(libnm-async-api): add nm_client_get_logging_async(). */
libnm: implement nm_client_get_logging()/nm_client_set_logging() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
ret = _nm_object_dbus_call_sync (client,
NULL,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"GetLogging",
g_variant_new ("()"),
G_VARIANT_TYPE ("(ss)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
if (!ret)
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
return FALSE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement nm_client_get_logging()/nm_client_set_logging() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
g_variant_get (ret,
"(ss)",
level,
domains);
return TRUE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_set_logging:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @level: (allow-none): logging level to set (%NULL or an empty string for no change)
* @domains: (allow-none): logging domains to set. The string should be a list of log
* domains separated by ",". (%NULL or an empty string for no change)
* @error: (allow-none): return location for a #GError, or %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Sets NetworkManager logging level and/or domains.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: %TRUE on success, %FALSE otherwise
libnm: mark more synchronous libnm API as deprecated This is a follow-up to commit e90684a169a7 ('libnm: deprecate synchronous/blocking API in libnm') to mark more of such synchronous API as deprecated.
2019-10-04 16:48:39 +02:00
*
* Deprecated: 1.22, use nm_client_set_logging_async() or GDBusConnection
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
gboolean
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_set_logging (NMClient *client, const char *level, const char *domains, GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (error == NULL || *error == NULL, FALSE);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: mark more synchronous libnm API as deprecated This is a follow-up to commit e90684a169a7 ('libnm: deprecate synchronous/blocking API in libnm') to mark more of such synchronous API as deprecated.
2019-10-04 16:48:39 +02:00
/* FIXME(libnm-async-api): add nm_client_set_logging_async(). */
libnm: implement nm_client_get_logging()/nm_client_set_logging() by using GDBusConnection directly
2019-10-04 16:18:51 +02:00
return _nm_object_dbus_call_sync_void (client,
NULL,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"SetLogging",
g_variant_new ("(ss)",
level ?: "",
domains ?: ""),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_permission_result:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @permission: the permission for which to return the result, one of #NMClientPermission
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Requests the result of a specific permission, which indicates whether the
* client can or cannot perform the action the permission represents
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: the permission's result, one of #NMClientPermissionResult
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
NMClientPermissionResult
nm_client_get_permission_result (NMClient *client, NMClientPermission permission)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NM_CLIENT_PERMISSION_RESULT_UNKNOWN);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NM_CLIENT_PERMISSION_RESULT_UNKNOWN;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_permission_result (NM_CLIENT_GET_PRIVATE (client)->manager, permission);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_connectivity:
* @client: an #NMClient
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets the current network connectivity state. Contrast
* nm_client_check_connectivity() and
* nm_client_check_connectivity_async(), which re-check the
* connectivity state first before returning any information.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: the current connectivity state
*/
NMConnectivityState
nm_client_get_connectivity (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm,core: don't mix up enum types Touches a weak spot on clang's soul.
2015-03-18 18:08:24 +01:00
g_return_val_if_fail (NM_IS_CLIENT (client), NM_CONNECTIVITY_UNKNOWN);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NM_CONNECTIVITY_UNKNOWN;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_connectivity (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_check_connectivity:
* @client: an #NMClient
* @cancellable: a #GCancellable
* @error: return location for a #GError
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Updates the network connectivity state and returns the (new)
* current state. Contrast nm_client_get_connectivity(), which returns
* the most recent known state without re-checking.
*
* This is a blocking call; use nm_client_check_connectivity_async()
* if you do not want to block.
*
* Returns: the (new) current connectivity state
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_check_connectivity_async() or GDBusConnection
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
*/
NMConnectivityState
nm_client_check_connectivity (NMClient *client,
GCancellable *cancellable,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_check_connectivity() by using GDBusConnection directly Note that nm_client_check_connectivity() has this odd behavior of updating the connectivity state right away. We keep doing that.
2019-10-04 16:18:51 +02:00
gs_unref_variant GVariant *ret = NULL;
guint32 connectivity;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NM_CONNECTIVITY_UNKNOWN);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement nm_client_check_connectivity() by using GDBusConnection directly Note that nm_client_check_connectivity() has this odd behavior of updating the connectivity state right away. We keep doing that.
2019-10-04 16:18:51 +02:00
ret = _nm_object_dbus_call_sync (client,
cancellable,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"CheckConnectivity",
g_variant_new ("()"),
G_VARIANT_TYPE ("(u)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
if (!ret)
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
return NM_CONNECTIVITY_UNKNOWN;
libnm: implement nm_client_check_connectivity() by using GDBusConnection directly Note that nm_client_check_connectivity() has this odd behavior of updating the connectivity state right away. We keep doing that.
2019-10-04 16:18:51 +02:00
g_variant_get (ret,
"(u)",
&connectivity);
/* upon receiving the synchronous response, we hack the NMClient state
* and update the property outside the ordered D-Bus messages (like
* "PropertiesChanged" signals).
*
* This is really ugly, we shouldn't do this. */
_nm_manager_set_connectivity_hack (NM_CLIENT_GET_PRIVATE (client)->manager,
connectivity);
return connectivity;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_check_connectivity_async:
* @client: an #NMClient
* @cancellable: a #GCancellable
* @callback: callback to call with the result
* @user_data: data for @callback.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Asynchronously updates the network connectivity state and invokes
* @callback when complete. Contrast nm_client_get_connectivity(),
* which (immediately) returns the most recent known state without
* re-checking, and nm_client_check_connectivity(), which blocks.
*/
void
nm_client_check_connectivity_async (NMClient *client,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_check_connectivity_async() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
g_return_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable));
_nm_object_dbus_call (client,
nm_client_check_connectivity_async,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"CheckConnectivity",
g_variant_new ("()"),
G_VARIANT_TYPE ("(u)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_variant_strip_dbus_error_cb);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
/**
* nm_client_check_connectivity_finish:
* @client: an #NMClient
* @result: the #GAsyncResult
* @error: return location for a #GError
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Retrieves the result of an nm_client_check_connectivity_async()
* call.
*
* Returns: the (new) current connectivity state
*/
NMConnectivityState
nm_client_check_connectivity_finish (NMClient *client,
GAsyncResult *result,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_check_connectivity_async() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
gs_unref_variant GVariant *ret = NULL;
guint32 connectivity;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NM_CONNECTIVITY_UNKNOWN);
libnm: implement nm_client_check_connectivity_async() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
g_return_val_if_fail (nm_g_task_is_valid (client, result, nm_client_check_connectivity_async), NM_CONNECTIVITY_UNKNOWN);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
libnm: implement nm_client_check_connectivity_async() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
ret = g_task_propagate_pointer (G_TASK (result), error);
if (!ret)
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
return NM_CONNECTIVITY_UNKNOWN;
libnm: implement nm_client_check_connectivity_async() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
g_variant_get (ret,
"(u)",
&connectivity);
return connectivity;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
* nm_client_save_hostname:
* @client: the %NMClient
* @hostname: (allow-none): the new persistent hostname to set, or %NULL to
* clear any existing persistent hostname
* @cancellable: a #GCancellable, or %NULL
* @error: return location for #GError
*
* Requests that the machine's persistent hostname be set to the specified value
* or cleared.
*
* Returns: %TRUE if the request was successful, %FALSE if it failed
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_save_hostname_async() or GDBusConnection
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
gboolean
nm_client_save_hostname (NMClient *client,
const char *hostname,
GCancellable *cancellable,
GError **error)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_save_hostname() by using GDBusConnection directly
2019-10-07 09:39:34 +02:00
g_return_val_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable), FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_save_hostname() by using GDBusConnection directly
2019-10-07 09:39:34 +02:00
return _nm_object_dbus_call_sync_void (client,
cancellable,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"SaveHostname",
g_variant_new ("(s)", hostname ?: ""),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_save_hostname_async:
* @client: the %NMClient
* @hostname: (allow-none): the new persistent hostname to set, or %NULL to
* clear any existing persistent hostname
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Requests that the machine's persistent hostname be set to the specified value
* or cleared.
**/
void
nm_client_save_hostname_async (NMClient *client,
const char *hostname,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_save_hostname_async() by using GDBusConnection directly
2019-10-07 09:43:47 +02:00
g_return_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable));
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_save_hostname_async() by using GDBusConnection directly
2019-10-07 09:43:47 +02:00
_nm_object_dbus_call (client,
nm_client_save_hostname_async,
cancellable,
callback,
user_data,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"SaveHostname",
g_variant_new ("(s)", hostname ?: ""),
G_VARIANT_TYPE ("()"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_void_strip_dbus_error_cb);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_save_hostname_finish:
* @client: the %NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: return location for #GError
*
* Gets the result of an nm_client_save_hostname_async() call.
*
* Returns: %TRUE if the request was successful, %FALSE if it failed
**/
gboolean
nm_client_save_hostname_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_save_hostname_async() by using GDBusConnection directly
2019-10-07 09:43:47 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_save_hostname_async), FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_save_hostname_async() by using GDBusConnection directly
2019-10-07 09:43:47 +02:00
return g_task_propagate_boolean (G_TASK (result), error);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: implement nm_client_save_hostname_async() by using GDBusConnection directly
2019-10-07 09:43:47 +02:00
/* Devices */
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_devices:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets all the known network devices. Use nm_device_get_type() or the
docs: misc small fixes Cleans up all of the warnings that aren't overly annoying to clean up.
2014-12-18 12:44:57 -05:00
* <literal>NM_IS_DEVICE_XXXX</literal> functions to determine what kind of
* device member of the returned array is, and then you may use device-specific
* methods such as nm_device_ethernet_get_hw_address().
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: (transfer none) (element-type NMDevice): a #GPtrArray
* containing all the #NMDevices. The returned array is owned by the
* #NMClient object and should not be modified.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
const GPtrArray *
nm_client_get_devices (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return &empty;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_devices (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
/**
* nm_client_get_all_devices:
* @client: a #NMClient
*
* Gets both real devices and device placeholders (eg, software devices which
* do not currently exist, but could be created automatically by NetworkManager
* if one of their NMDevice::ActivatableConnections was activated). Use
* nm_device_is_real() to determine whether each device is a real device or
* a placeholder.
*
* Use nm_device_get_type() or the NM_IS_DEVICE_XXXX() functions to determine
* what kind of device each member of the returned array is, and then you may
* use device-specific methods such as nm_device_ethernet_get_hw_address().
*
* Returns: (transfer none) (element-type NMDevice): a #GPtrArray
* containing all the #NMDevices. The returned array is owned by the
* #NMClient object and should not be modified.
*
* Since: 1.2
**/
const GPtrArray *
nm_client_get_all_devices (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return &empty;
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
return nm_manager_get_all_devices (NM_CLIENT_GET_PRIVATE (client)->manager);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_device_by_path:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @object_path: the object path to search for
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets a #NMDevice from a #NMClient.
*
* Returns: (transfer none): the #NMDevice for the given @object_path or %NULL if none is found.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
NMDevice *
nm_client_get_device_by_path (NMClient *client, const char *object_path)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
g_return_val_if_fail (object_path, NULL);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NULL;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_device_by_path (NM_CLIENT_GET_PRIVATE (client)->manager, object_path);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_device_by_iface:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @iface: the interface name to search for
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets a #NMDevice from a #NMClient.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: (transfer none): the #NMDevice for the given @iface or %NULL if none is found.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
NMDevice *
nm_client_get_device_by_iface (NMClient *client, const char *iface)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
g_return_val_if_fail (iface, NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NULL;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_device_by_iface (NM_CLIENT_GET_PRIVATE (client)->manager, iface);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
/* Active Connections */
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_active_connections:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets the active connections.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: (transfer none) (element-type NMActiveConnection): a #GPtrArray
* containing all the active #NMActiveConnections.
* The returned array is owned by the client and should not be modified.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
const GPtrArray *
nm_client_get_active_connections (NMClient *client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return &empty;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_active_connections (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_get_primary_connection:
* @client: an #NMClient
*
* Gets the #NMActiveConnection corresponding to the primary active
* network device.
*
* In particular, when there is no VPN active, or the VPN does not
* have the default route, this returns the active connection that has
* the default route. If there is a VPN active with the default route,
* then this function returns the active connection that contains the
* route to the VPN endpoint.
*
* If there is no default route, or the default route is over a
* non-NetworkManager-recognized device, this will return %NULL.
*
* Returns: (transfer none): the appropriate #NMActiveConnection, if
* any
*/
NMActiveConnection *
nm_client_get_primary_connection (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NULL;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_primary_connection (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
/**
* nm_client_get_activating_connection:
* @client: an #NMClient
*
* Gets the #NMActiveConnection corresponding to a
* currently-activating connection that is expected to become the new
* #NMClient:primary-connection upon successful activation.
*
* Returns: (transfer none): the appropriate #NMActiveConnection, if
* any.
*/
NMActiveConnection *
nm_client_get_activating_connection (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return NULL;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
return nm_manager_get_activating_connection (NM_CLIENT_GET_PRIVATE (client)->manager);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
static void
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
activate_connection_cb (GObject *object,
GAsyncResult *result,
gpointer user_data)
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
NMClient *self;
gs_unref_object GTask *task = user_data;
gs_unref_variant GVariant *ret = NULL;
const char *v_active_connection;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
GError *error = NULL;
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
ret = g_dbus_connection_call_finish (G_DBUS_CONNECTION (object), result, &error);
if (!ret) {
g_dbus_error_strip_remote_error (error);
g_task_return_error (task, error);
return;
}
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
self = g_task_get_source_object (task);
g_variant_get (ret, "(&o)", &v_active_connection);
nm_manager_wait_for_active_connection (NM_CLIENT_GET_PRIVATE (self)->manager,
v_active_connection,
NULL,
NULL,
g_steal_pointer (&task));
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
/**
* nm_client_activate_connection_async:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @connection: (allow-none): an #NMConnection
* @device: (allow-none): the #NMDevice
* @specific_object: (allow-none): the object path of a connection-type-specific
* object this activation should use. This parameter is currently ignored for
* wired and mobile broadband connections, and the value of %NULL should be used
* (ie, no specific object). For Wi-Fi or WiMAX connections, pass the object
* path of a #NMAccessPoint or #NMWimaxNsp owned by @device, which you can
* get using nm_object_get_path(), and which will be used to complete the
* details of the newly added connection.
* @cancellable: a #GCancellable, or %NULL
* @callback: callback to be called when the activation has started
* @user_data: caller-specific data passed to @callback
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Asynchronously starts a connection to a particular network using the
* configuration settings from @connection and the network device @device.
* Certain connection types also take a "specific object" which is the object
* path of a connection- specific object, like an #NMAccessPoint for Wi-Fi
* connections, or an #NMWimaxNsp for WiMAX connections, to which you wish to
* connect. If the specific object is not given, NetworkManager can, in some
* cases, automatically determine which network to connect to given the settings
* in @connection.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* If @connection is not given for a device-based activation, NetworkManager
* picks the best available connection for the device and activates it.
*
* Note that the callback is invoked when NetworkManager has started activating
all/trivial: fix few comment typos
2017-05-11 12:08:02 +02:00
* the new connection, not when it finishes. You can use the returned
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* #NMActiveConnection object (in particular, #NMActiveConnection:state) to
* track the activation to its completion.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
void
nm_client_activate_connection_async (NMClient *client,
NMConnection *connection,
NMDevice *device,
const char *specific_object,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
const char *arg_connection = NULL;
const char *arg_device = NULL;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
if (connection) {
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_if_fail (NM_IS_CONNECTION (connection));
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
arg_connection = nm_connection_get_path (connection);
g_return_if_fail (arg_connection);
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
if (device) {
g_return_if_fail (NM_IS_DEVICE (device));
arg_device = nm_object_get_path (NM_OBJECT (device));
g_return_if_fail (arg_device);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
_nm_object_dbus_call (client,
nm_client_activate_connection_async,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"ActivateConnection",
g_variant_new ("(ooo)",
arg_connection ?: "/",
arg_device ?: "/",
specific_object ?: "/"),
G_VARIANT_TYPE ("(o)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
activate_connection_cb);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_activate_connection_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets the result of a call to nm_client_activate_connection_async().
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: (transfer full): the new #NMActiveConnection on success, %NULL on
* failure, in which case @error will be set.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
NMActiveConnection *
nm_client_activate_connection_finish (NMClient *client,
GAsyncResult *result,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
nm_auto_free_activate_result _NMActivateResult *r = NULL;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_activate_connection_async), NULL);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
r = g_task_propagate_pointer (G_TASK (result), error);
if (!r)
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
return NULL;
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
return g_steal_pointer (&r->active);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
static void
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
_add_and_activate_connection_done (GObject *object,
GAsyncResult *result,
gboolean use_add_and_activate_v2,
GTask *task_take)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
_nm_unused gs_unref_object GTask *task = task_take;
NMClient *self;
gs_unref_variant GVariant *ret = NULL;
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
GError *error = NULL;
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
const char *v_path;
const char *v_active_connection;
gs_unref_variant GVariant *v_result = NULL;
ret = g_dbus_connection_call_finish (G_DBUS_CONNECTION (object), result, &error);
if (!ret) {
g_dbus_error_strip_remote_error (error);
g_task_return_error (task, error);
return;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
self = g_task_get_source_object (task);
if (use_add_and_activate_v2) {
g_variant_get (ret,
"(&o&o@a{sv})",
&v_path,
&v_active_connection,
&v_result);
} else {
g_variant_get (ret,
"(&o&o)",
&v_path,
&v_active_connection);
}
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
nm_manager_wait_for_active_connection (NM_CLIENT_GET_PRIVATE (self)->manager,
v_active_connection,
v_path,
g_steal_pointer (&v_result),
g_steal_pointer (&task));
}
static void
_add_and_activate_connection_v1_cb (GObject *object, GAsyncResult *result, gpointer user_data)
{
_add_and_activate_connection_done (object, result, FALSE, user_data);
}
static void
_add_and_activate_connection_v2_cb (GObject *object, GAsyncResult *result, gpointer user_data)
{
_add_and_activate_connection_done (object, result, TRUE, user_data);
}
static void
_add_and_activate_connection (NMClient *client,
gboolean is_v2,
NMConnection *partial,
NMDevice *device,
const char *specific_object,
GVariant *options,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
GVariant *arg_connection = NULL;
gboolean use_add_and_activate_v2 = FALSE;
const char *arg_device = NULL;
gpointer source_tag;
g_return_if_fail (NM_IS_CLIENT (client));
g_return_if_fail (!partial || NM_IS_CONNECTION (partial));
if (device) {
g_return_if_fail (NM_IS_DEVICE (device));
arg_device = nm_object_get_path (NM_OBJECT (device));
g_return_if_fail (arg_device);
}
if (partial)
arg_connection = nm_connection_to_dbus (partial, NM_CONNECTION_SERIALIZE_ALL);
if (!arg_connection)
arg_connection = g_variant_new_array (G_VARIANT_TYPE ("{sa{sv}}"), NULL, 0);
if (is_v2) {
if (!options)
options = g_variant_new_array (G_VARIANT_TYPE ("{sv}"), NULL, 0);
use_add_and_activate_v2 = TRUE;
source_tag = nm_client_add_and_activate_connection2;
} else {
if (options) {
if (g_variant_n_children (options) > 0)
use_add_and_activate_v2 = TRUE;
else
nm_clear_pointer (&options, nm_g_variant_unref_floating);
}
source_tag = nm_client_add_and_activate_connection_async;
}
if (use_add_and_activate_v2) {
_nm_object_dbus_call (client,
source_tag,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"AddAndActivateConnection2",
g_variant_new ("(@a{sa{sv}}oo@a{sv})",
arg_connection,
arg_device ?: "/",
specific_object ?: "/",
options),
G_VARIANT_TYPE ("(ooa{sv})"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
_add_and_activate_connection_v2_cb);
} else {
_nm_object_dbus_call (client,
source_tag,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"AddAndActivateConnection",
g_variant_new ("(@a{sa{sv}}oo)",
arg_connection,
arg_device ?: "/",
specific_object ?: "/"),
G_VARIANT_TYPE ("(oo)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
_add_and_activate_connection_v1_cb);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_add_and_activate_connection_async:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @partial: (allow-none): an #NMConnection to add; the connection may be
* partially filled (or even %NULL) and will be completed by NetworkManager
* using the given @device and @specific_object before being added
* @device: the #NMDevice
* @specific_object: (allow-none): the object path of a connection-type-specific
* object this activation should use. This parameter is currently ignored for
* wired and mobile broadband connections, and the value of %NULL should be used
* (ie, no specific object). For Wi-Fi or WiMAX connections, pass the object
* path of a #NMAccessPoint or #NMWimaxNsp owned by @device, which you can
* get using nm_object_get_path(), and which will be used to complete the
* details of the newly added connection.
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
* If the variant is floating, it will be consumed.
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @cancellable: a #GCancellable, or %NULL
* @callback: callback to be called when the activation has started
* @user_data: caller-specific data passed to @callback
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Adds a new connection using the given details (if any) as a template,
* automatically filling in missing settings with the capabilities of the given
* device and specific object. The new connection is then asynchronously
* activated as with nm_client_activate_connection_async(). Cannot be used for
* VPN connections at this time.
libnm: return errors in nm_client_networking_set_enabled() and do not print an error in the library. The caller can decide what to do on an error.
2014-10-01 11:02:16 +02:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Note that the callback is invoked when NetworkManager has started activating
* the new connection, not when it finishes. You can used the returned
* #NMActiveConnection object (in particular, #NMActiveConnection:state) to
* track the activation to its completion.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
void
nm_client_add_and_activate_connection_async (NMClient *client,
NMConnection *partial,
NMDevice *device,
const char *specific_object,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
_add_and_activate_connection (client,
FALSE,
partial,
device,
specific_object,
NULL,
cancellable,
callback,
user_data);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_add_and_activate_connection_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets the result of a call to nm_client_add_and_activate_connection_async().
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* You can call nm_active_connection_get_connection() on the returned
* #NMActiveConnection to find the path of the created #NMConnection.
*
* Returns: (transfer full): the new #NMActiveConnection on success, %NULL on
* failure, in which case @error will be set.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
NMActiveConnection *
nm_client_add_and_activate_connection_finish (NMClient *client,
GAsyncResult *result,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
nm_auto_free_activate_result _NMActivateResult *r = NULL;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_add_and_activate_connection_async), NULL);
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
r = g_task_propagate_pointer (G_TASK (result), error);
if (!r)
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
return NULL;
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
return g_steal_pointer (&r->active);
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
}
/**
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
* nm_client_add_and_activate_connection2:
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
* @client: a #NMClient
* @partial: (allow-none): an #NMConnection to add; the connection may be
* partially filled (or even %NULL) and will be completed by NetworkManager
* using the given @device and @specific_object before being added
* @device: the #NMDevice
* @specific_object: (allow-none): the object path of a connection-type-specific
* object this activation should use. This parameter is currently ignored for
* wired and mobile broadband connections, and the value of %NULL should be used
* (ie, no specific object). For Wi-Fi or WiMAX connections, pass the object
* path of a #NMAccessPoint or #NMWimaxNsp owned by @device, which you can
* get using nm_object_get_path(), and which will be used to complete the
* details of the newly added connection.
* @options: a #GVariant containing a dictionary with options, or %NULL
* @cancellable: a #GCancellable, or %NULL
* @callback: callback to be called when the activation has started
* @user_data: caller-specific data passed to @callback
*
* Adds a new connection using the given details (if any) as a template,
* automatically filling in missing settings with the capabilities of the given
* device and specific object. The new connection is then asynchronously
* activated as with nm_client_activate_connection_async(). Cannot be used for
* VPN connections at this time.
*
* Note that the callback is invoked when NetworkManager has started activating
* the new connection, not when it finishes. You can used the returned
* #NMActiveConnection object (in particular, #NMActiveConnection:state) to
* track the activation to its completion.
*
* This is identitcal to nm_client_add_and_activate_connection_async() but takes
* a further @options parameter. Currently the following options are supported
* by the daemon:
* * "persist": A string describing how the connection should be stored.
* The default is "disk", but it can be modified to "memory" (until
* the daemon quits) or "volatile" (will be deleted on disconnect).
all: rename "bind" option for AddAndActivateConnection2 to "bind-activation" "bind" specifically binds the lifetime of the activation (NMActiveConnection). In combination with "persist=volatile", the lifetime of the NMSettingsConnection is indirectly bound to the NMActiveConnection. But still these concepts make sense independently. In the future, it may make sense to also bind the lifetime of the NMSettingsConnection to the D-Bus client. Hence, rename the option to allow for the distinction. Also, belatedly fix libnm comment about "bind" only working with "persist" "volatile". Fixes: eb883e34a5889812d35e5c2d7bc6051723001a3a
2018-11-19 11:16:44 +01:00
* * "bind-activation": Bind the connection lifetime to something. The default is "none",
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
* meaning an explicit disconnect is needed. The value "dbus-client"
all: rename "bind" option for AddAndActivateConnection2 to "bind-activation" "bind" specifically binds the lifetime of the activation (NMActiveConnection). In combination with "persist=volatile", the lifetime of the NMSettingsConnection is indirectly bound to the NMActiveConnection. But still these concepts make sense independently. In the future, it may make sense to also bind the lifetime of the NMSettingsConnection to the D-Bus client. Hence, rename the option to allow for the distinction. Also, belatedly fix libnm comment about "bind" only working with "persist" "volatile". Fixes: eb883e34a5889812d35e5c2d7bc6051723001a3a
2018-11-19 11:16:44 +01:00
* means the connection will automatically be deactivated when the calling
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
* DBus client disappears from the system bus.
*
* Since: 1.16
**/
void
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
nm_client_add_and_activate_connection2 (NMClient *client,
NMConnection *partial,
NMDevice *device,
const char *specific_object,
GVariant *options,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
_add_and_activate_connection (client,
TRUE,
partial,
device,
specific_object,
options,
cancellable,
callback,
user_data);
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
}
/**
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
* nm_client_add_and_activate_connection2_finish:
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
nm: Fix syntax on introspection annotations Various annotations were added using multiple colons, while only one has to be added or g-ir-introspect will consider them part of the description https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/94 (cherry picked from commit 73005fcf5b957a4cf7f8244da85ade0214db7606)
2019-03-06 20:04:50 +01:00
* @out_result: (allow-none) (transfer full): the output result
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
* of type "a{sv}" returned by D-Bus' AddAndActivate2 call. Currently no
* output is implemented yet.
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
*
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
* Gets the result of a call to nm_client_add_and_activate_connection2().
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
*
* You can call nm_active_connection_get_connection() on the returned
* #NMActiveConnection to find the path of the created #NMConnection.
*
* Returns: (transfer full): the new #NMActiveConnection on success, %NULL on
* failure, in which case @error will be set.
**/
NMActiveConnection *
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
nm_client_add_and_activate_connection2_finish (NMClient *client,
GAsyncResult *result,
GVariant **out_result,
GError **error)
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
{
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
nm_auto_free_activate_result _NMActivateResult *r = NULL;
libnm: Add support to pass options to AddAndActivateConnection This adds the new methods nm_client_add_and_activate_connection_options_* and ports the existing methods to use the new AddAndActivateConnection2 call rather than AddAndActivateConnection, allowing further parameters to be passed in.
2018-10-26 13:44:38 +02:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_add_and_activate_connection2), NULL);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
r = g_task_propagate_pointer (G_TASK (result), error);
if (!r) {
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
NM_SET_OUT (out_result, NULL);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
return NULL;
all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
2018-12-20 07:48:31 +01:00
}
libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly We still need the bits in "nm-manager.c", to wait until the NMActiveConnection instance is ready. This is now done by nm_manager_complete_active_connection().
2019-10-03 16:30:25 +02:00
NM_SET_OUT (out_result, g_steal_pointer (&r->add_and_activate_output));
return g_steal_pointer (&r->active);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_deactivate_connection:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @active: the #NMActiveConnection to deactivate
* @cancellable: a #GCancellable, or %NULL
* @error: location for a #GError, or %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Deactivates an active #NMActiveConnection.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: success or failure
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_deactivate_connection_async() or GDBusConnection
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
gboolean
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
nm_client_deactivate_connection (NMClient *client,
NMActiveConnection *active,
GCancellable *cancellable,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_deactivate_connection() by using GDBusConnection directly Eventually, I will refactor libnm to no longer use gdbus-codegen and no GDBusProxy. In preparation of that, we must stop using that API. As first step, change nm_client_deactivate_connection(). Note how this was done previously: - nm_client_deactivate_connection() calls nm_manager_deactivate_connection() - nmdbus_manager_call_deactivate_connection_sync() calls g_dbus_proxy_call_sync() - g_dbus_proxy_call_sync() calls g_dbus_connection_call_sync() Currently this is still a bit ugly, because NMClient doesn't directly track the GDBusConnection nor the name owner. Instead, we need to peel it out of the object manager. One day, that will all be nicer, but first get rid of gdbus-codegen.
2019-10-01 16:51:10 +02:00
const char *active_path;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_val_if_fail (NM_IS_ACTIVE_CONNECTION (active), FALSE);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement nm_client_deactivate_connection() by using GDBusConnection directly Eventually, I will refactor libnm to no longer use gdbus-codegen and no GDBusProxy. In preparation of that, we must stop using that API. As first step, change nm_client_deactivate_connection(). Note how this was done previously: - nm_client_deactivate_connection() calls nm_manager_deactivate_connection() - nmdbus_manager_call_deactivate_connection_sync() calls g_dbus_proxy_call_sync() - g_dbus_proxy_call_sync() calls g_dbus_connection_call_sync() Currently this is still a bit ugly, because NMClient doesn't directly track the GDBusConnection nor the name owner. Instead, we need to peel it out of the object manager. One day, that will all be nicer, but first get rid of gdbus-codegen.
2019-10-01 16:51:10 +02:00
active_path = nm_object_get_path (NM_OBJECT (active));
g_return_val_if_fail (active_path, FALSE);
return _nm_object_dbus_call_sync_void (client,
cancellable,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"DeactivateConnection",
g_variant_new ("(o)", active_path),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_deactivate_connection_async:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* @client: a #NMClient
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* @active: the #NMActiveConnection to deactivate
* @cancellable: a #GCancellable, or %NULL
* @callback: callback to be called when the deactivation has completed
* @user_data: caller-specific data passed to @callback
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Asynchronously deactivates an active #NMActiveConnection.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
void
nm_client_deactivate_connection_async (NMClient *client,
NMActiveConnection *active,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: implement nm_client_deactivate_connection_async() by using GDBusConnection directly
2019-10-02 13:38:36 +02:00
const char *active_path;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
g_return_if_fail (NM_IS_CLIENT (client));
g_return_if_fail (NM_IS_ACTIVE_CONNECTION (active));
libnm: implement nm_client_deactivate_connection_async() by using GDBusConnection directly
2019-10-02 13:38:36 +02:00
active_path = nm_object_get_path (NM_OBJECT (active));
g_return_if_fail (active_path);
_nm_object_dbus_call (client,
nm_client_deactivate_connection_async,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"DeactivateConnection",
g_variant_new ("(o)", active_path),
G_VARIANT_TYPE ("()"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_void_strip_dbus_error_cb);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* nm_client_deactivate_connection_finish:
* @client: a #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Gets the result of a call to nm_client_deactivate_connection_async().
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: (trivial) reorder NMClient function declarations/code Rearrange the NMClient function declarations and the functions themselves, and group them into "general", "device", and "active connection" sections. No code changes, just moving things around.
2014-09-18 16:11:00 -04:00
* Returns: success or failure
**/
gboolean
nm_client_deactivate_connection_finish (NMClient *client,
GAsyncResult *result,
GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: clean up NMClient semantics when NM is not running Add a single function to check if NM is running and set a GError if not, then use it as appropriate. Don't bother to check if NM is running in get_*() functions if nm_running_changed_cb() would have reset the field anyway (and fix that up to reset a few more fields).
2014-10-07 09:26:40 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_deactivate_connection_async() by using GDBusConnection directly
2019-10-02 13:38:36 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_deactivate_connection_async), FALSE);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement nm_client_deactivate_connection_async() by using GDBusConnection directly
2019-10-02 13:38:36 +02:00
return g_task_propagate_boolean (G_TASK (result), error);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/* Connections */
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
libnm: change GSList to GPtrArray in libnm methods libnm mostly used GPtrArrays in its APIs, except that arrays of connections were usually GSLists. Fix this and make them GPtrArrays too (and rename nm_client_list_connections() to nm_client_get_connections() to match everything else).
2014-10-22 12:32:46 -04:00
* nm_client_get_connections:
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
* @client: the %NMClient
*
libnm: change GSList to GPtrArray in libnm methods libnm mostly used GPtrArrays in its APIs, except that arrays of connections were usually GSLists. Fix this and make them GPtrArrays too (and rename nm_client_list_connections() to nm_client_get_connections() to match everything else).
2014-10-22 12:32:46 -04:00
* Returns: (transfer none) (element-type NMRemoteConnection): an array
* containing all connections provided by the remote settings service. The
* returned array is owned by the #NMClient object and should not be modified.
libnm: add code comments to hint that NMConnection might not validate
2016-03-23 17:36:28 +01:00
*
* The connections are as received from D-Bus and might not validate according
* to nm_connection_verify().
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
libnm: change GSList to GPtrArray in libnm methods libnm mostly used GPtrArrays in its APIs, except that arrays of connections were usually GSLists. Fix this and make them GPtrArrays too (and rename nm_client_list_connections() to nm_client_get_connections() to match everything else).
2014-10-22 12:32:46 -04:00
const GPtrArray *
nm_client_get_connections (NMClient *client)
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
return &empty;
libnm: change GSList to GPtrArray in libnm methods libnm mostly used GPtrArrays in its APIs, except that arrays of connections were usually GSLists. Fix this and make them GPtrArrays too (and rename nm_client_list_connections() to nm_client_get_connections() to match everything else).
2014-10-22 12:32:46 -04:00
return nm_remote_settings_get_connections (NM_CLIENT_GET_PRIVATE (client)->settings);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_get_connection_by_id:
* @client: the %NMClient
* @id: the id of the remote connection
*
* Returns the first matching %NMRemoteConnection matching a given @id.
*
* Returns: (transfer none): the remote connection object on success, or %NULL if no
* matching object was found.
libnm: add code comments to hint that NMConnection might not validate
2016-03-23 17:36:28 +01:00
*
* The connection is as received from D-Bus and might not validate according
* to nm_connection_verify().
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
NMRemoteConnection *
nm_client_get_connection_by_id (NMClient *client, const char *id)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
g_return_val_if_fail (id != NULL, NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
libnm: fix empty statements that were supposed to return NULL Discovered thanks to `-Wunused-value` when building on openSUSE Leap 42.3.
2018-01-17 17:39:24 +01:00
return NULL;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return nm_remote_settings_get_connection_by_id (NM_CLIENT_GET_PRIVATE (client)->settings, id);
}
/**
* nm_client_get_connection_by_path:
* @client: the %NMClient
* @path: the D-Bus object path of the remote connection
*
* Returns the %NMRemoteConnection representing the connection at @path.
*
* Returns: (transfer none): the remote connection object on success, or %NULL if the object was
* not known
libnm: add code comments to hint that NMConnection might not validate
2016-03-23 17:36:28 +01:00
*
* The connection is as received from D-Bus and might not validate according
* to nm_connection_verify().
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
NMRemoteConnection *
nm_client_get_connection_by_path (NMClient *client, const char *path)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
g_return_val_if_fail (path != NULL, NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
libnm: fix empty statements that were supposed to return NULL Discovered thanks to `-Wunused-value` when building on openSUSE Leap 42.3.
2018-01-17 17:39:24 +01:00
return NULL;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return nm_remote_settings_get_connection_by_path (NM_CLIENT_GET_PRIVATE (client)->settings, path);
}
/**
* nm_client_get_connection_by_uuid:
* @client: the %NMClient
* @uuid: the UUID of the remote connection
*
* Returns the %NMRemoteConnection identified by @uuid.
*
* Returns: (transfer none): the remote connection object on success, or %NULL if the object was
* not known
libnm: add code comments to hint that NMConnection might not validate
2016-03-23 17:36:28 +01:00
*
* The connection is as received from D-Bus and might not validate according
* to nm_connection_verify().
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
NMRemoteConnection *
nm_client_get_connection_by_uuid (NMClient *client, const char *uuid)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
g_return_val_if_fail (uuid != NULL, NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (!nm_client_get_nm_running (client))
libnm: fix empty statements that were supposed to return NULL Discovered thanks to `-Wunused-value` when building on openSUSE Leap 42.3.
2018-01-17 17:39:24 +01:00
return NULL;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return nm_remote_settings_get_connection_by_uuid (NM_CLIENT_GET_PRIVATE (client)->settings, uuid);
}
static void
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
_add_connection_cb (GObject *source,
GAsyncResult *result,
gboolean with_extra_arg,
gpointer user_data)
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
{
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
NMClient *self;
gs_unref_variant GVariant *ret = NULL;
gs_unref_object GTask *task = user_data;
gs_unref_variant GVariant *v_result = NULL;
const char *v_path;
GError *error = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
ret = g_dbus_connection_call_finish (G_DBUS_CONNECTION (source), result, &error);
if (!ret) {
g_dbus_error_strip_remote_error (error);
g_task_return_error (task, error);
return;
}
if (with_extra_arg) {
g_variant_get (ret,
"(&o@a{sv})",
&v_path,
&v_result);
} else {
g_variant_get (ret,
"(&o)",
&v_path);
}
self = g_task_get_source_object (task);
nm_remote_settings_wait_for_connection (NM_CLIENT_GET_PRIVATE (self)->settings,
v_path,
g_steal_pointer (&v_result),
g_steal_pointer (&task));
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
}
static void
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
_add_connection_cb_without_extra_result (GObject *object, GAsyncResult *result, gpointer user_data)
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
{
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
_add_connection_cb (object, result, FALSE, user_data);
}
static void
_add_connection_cb_with_extra_result (GObject *object, GAsyncResult *result, gpointer user_data)
{
_add_connection_cb (object, result, TRUE, user_data);
}
static void
_add_connection_call (NMClient *self,
gpointer source_tag,
gboolean ignore_out_result,
GVariant *settings,
NMSettingsAddConnection2Flags flags,
GVariant *args,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (self));
g_return_if_fail (!settings || g_variant_is_of_type (settings, G_VARIANT_TYPE ("a{sa{sv}}")));
g_return_if_fail (!args || g_variant_is_of_type (args, G_VARIANT_TYPE ("a{sv}")));
if (!settings)
settings = g_variant_new_array (G_VARIANT_TYPE ("{sa{sv}}"), NULL, 0);
/* Although AddConnection2() being capable to handle also AddConnection() and
* AddConnectionUnsaved() variants, we prefer to use the old D-Bus methods when
* they are sufficient. The reason is that libnm should avoid hard dependencies
* on 1.20 API whenever possible. */
if ( ignore_out_result
&& flags == NM_SETTINGS_ADD_CONNECTION2_FLAG_TO_DISK) {
_nm_object_dbus_call (self,
source_tag,
cancellable,
callback,
user_data,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"AddConnection",
g_variant_new ("(@a{sa{sv}})", settings),
G_VARIANT_TYPE ("(o)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
_add_connection_cb_without_extra_result);
} else if ( ignore_out_result
&& flags == NM_SETTINGS_ADD_CONNECTION2_FLAG_IN_MEMORY) {
_nm_object_dbus_call (self,
source_tag,
cancellable,
callback,
user_data,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"AddConnectionUnsaved",
g_variant_new ("(@a{sa{sv}})", settings),
G_VARIANT_TYPE ("(o)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
_add_connection_cb_without_extra_result);
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
} else {
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
_nm_object_dbus_call (self,
source_tag,
cancellable,
callback,
user_data,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"AddConnection2",
g_variant_new ("(@a{sa{sv}}u@a{sv})",
settings,
(guint32) flags,
args
?: g_variant_new_array (G_VARIANT_TYPE ("{sv}"), NULL, 0)),
G_VARIANT_TYPE ("(oa{sv})"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
_add_connection_cb_with_extra_result);
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
}
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
}
static NMRemoteConnection *
_add_connection_call_finish (NMClient *client,
GAsyncResult *result,
gpointer source_tag,
GVariant **out_result,
GError **error)
{
nm_auto_free_add_connection_result_data NMAddConnectionResultData *result_data = NULL;
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
g_return_val_if_fail (nm_g_task_is_valid (result, client, source_tag), NULL);
result_data = g_task_propagate_pointer (G_TASK (result), error);
if (!result_data) {
NM_SET_OUT (out_result, NULL);
return NULL;
}
nm_assert (NM_IS_REMOTE_CONNECTION (result_data->connection));
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
NM_SET_OUT (out_result, g_steal_pointer (&result_data->extra_results));
return g_steal_pointer (&result_data->connection);
}
void
nm_add_connection_result_data_free (NMAddConnectionResultData *result_data)
{
nm_g_object_unref (result_data->connection);
nm_g_variant_unref (result_data->extra_results);
nm_g_slice_free (result_data);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_add_connection_async:
* @client: the %NMClient
* @connection: the connection to add. Note that this object's settings will be
* added, not the object itself
* @save_to_disk: whether to immediately save the connection to disk
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Requests that the remote settings service add the given settings to a new
* connection. If @save_to_disk is %TRUE, the connection is immediately written
* to disk; otherwise it is initially only stored in memory, but may be saved
* later by calling the connection's nm_remote_connection_commit_changes()
* method.
*
* @connection is untouched by this function and only serves as a template of
* the settings to add. The #NMRemoteConnection object that represents what
* NetworkManager actually added is returned to @callback when the addition
* operation is complete.
*
* Note that the #NMRemoteConnection returned in @callback may not contain
* identical settings to @connection as NetworkManager may perform automatic
* completion and/or normalization of connection properties.
**/
void
nm_client_add_connection_async (NMClient *client,
NMConnection *connection,
gboolean save_to_disk,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CONNECTION (connection));
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
_add_connection_call (client,
nm_client_add_connection_async,
TRUE,
nm_connection_to_dbus (connection, NM_CONNECTION_SERIALIZE_ALL),
save_to_disk
? NM_SETTINGS_ADD_CONNECTION2_FLAG_TO_DISK
: NM_SETTINGS_ADD_CONNECTION2_FLAG_IN_MEMORY,
NULL,
cancellable,
callback,
user_data);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_add_connection_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
* Gets the result of a call to nm_client_add_connection_async().
*
* Returns: (transfer full): the new #NMRemoteConnection on success, %NULL on
* failure, in which case @error will be set.
**/
NMRemoteConnection *
nm_client_add_connection_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
return _add_connection_call_finish (client,
result,
nm_client_add_connection_async,
NULL,
error);
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
}
/**
* nm_client_add_connection2:
* @client: the %NMClient
* @settings: the "a{sa{sv}}" #GVariant with the content of the setting.
* @flags: the %NMSettingsAddConnection2Flags argument.
* @args: (allow-none): the "a{sv}" #GVariant with extra argument or %NULL
* for no extra arguments.
* @ignore_out_result: this function wraps AddConnection2(), which has an
* additional result "a{sv}" output parameter. By setting this to %TRUE,
* you signal that you are not interested in that output parameter.
* This allows the function to fall back to AddConnection() and AddConnectionUnsaved(),
* which is interesting if you run against an older server version that does
* not yet provide AddConnection2(). By setting this to %FALSE, the function
* under the hood always calls AddConnection2().
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Call AddConnection2() D-Bus API asynchronously.
*
* Since: 1.20
**/
void
nm_client_add_connection2 (NMClient *client,
GVariant *settings,
NMSettingsAddConnection2Flags flags,
GVariant *args,
gboolean ignore_out_result,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
_add_connection_call (client,
nm_client_add_connection2,
ignore_out_result,
settings,
flags,
args,
cancellable,
callback,
user_data);
core,libnm: add AddConnection2() D-Bus API to block autoconnect from the start It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
2019-07-09 15:22:01 +02:00
}
/**
* nm_client_add_connection2_finish:
* @client: the #NMClient
* @result: the #GAsyncResult
* @out_result: (allow-none) (transfer full) (out): the output #GVariant
* from AddConnection2().
* If you care about the output result, then the "ignore_out_result"
* parameter of nm_client_add_connection2() must not be set to %TRUE.
* @error: (allow-none): the error argument.
*
* Returns: (transfer full): on success, a pointer to the added
* #NMRemoteConnection.
*
* Since: 1.20
*/
NMRemoteConnection *
nm_client_add_connection2_finish (NMClient *client,
GAsyncResult *result,
GVariant **out_result,
GError **error)
{
libnm: implement nm_client_add_connection*() by using GDBusConnection directly
2019-10-07 09:48:09 +02:00
return _add_connection_call_finish (client,
result,
nm_client_add_connection2,
out_result,
error);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_load_connections:
* @client: the %NMClient
libnm: fix introspection annotations for nm_client_load_connections() Add the "(array zero-terminated=1)" GLib introspection annotation when the parameter is a NULL-terminated string array. https://mail.gnome.org/archives/networkmanager-list/2016-August/msg00017.html Reported-by: Petr Horacek <phoracek@redhat.com>
2016-08-04 13:38:24 +02:00
* @filenames: (array zero-terminated=1): %NULL-terminated array of filenames to load
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
* @failures: (out) (transfer full): on return, a %NULL-terminated array of
* filenames that failed to load
* @cancellable: a #GCancellable, or %NULL
* @error: return location for #GError
*
* Requests that the remote settings service load or reload the given files,
* adding or updating the connections described within.
*
* The changes to the indicated files will not yet be reflected in
* @client's connections array when the function returns.
*
* If all of the indicated files were successfully loaded, the
* function will return %TRUE, and @failures will be set to %NULL. If
* NetworkManager tried to load the files, but some (or all) failed,
* then @failures will be set to a %NULL-terminated array of the
* filenames that failed to load.
*
libnm: fix return value for nm_remote_settings_load_connections() to ignore server result nm_remote_settings_load_connections() and nm_remote_settings_load_connections_async() behave inconsistently. It's unexpected, that a FALSE return value may leave @error unset. Note that before commit 22e830f0469a ('settings/d-bus: fix boolean return value of "LoadConnections"'), the server boolean response would have been bogus anyway (at least for some versions). Unify the behavior, and ignore the boolean return value.
2019-10-06 23:19:32 +02:00
* Returns: %TRUE on success.
*
* Warning: before libnm 1.22, the boolean return value was inconsistent.
* That is made worse, because when running against certain server versions
* before 1.20, the server would return wrong values for success/failure.
* This means, if you use this function in libnm before 1.22, you are advised
* to ignore the boolean return value and only look at @failures and @error.
* With libnm >= 1.22, the boolean return value corresponds to whether @error was
* set. Note that even in the success case, you might have individual @failures.
* With 1.22, the return value is consistent with nm_client_load_connections_finish().
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_load_connections_async() or GDBusConnection
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
gboolean
nm_client_load_connections (NMClient *client,
char **filenames,
char ***failures,
GCancellable *cancellable,
GError **error)
{
libnm: implement nm_client_load_connections() by using GDBusConnection directly
2019-10-06 22:50:29 +02:00
gs_unref_variant GVariant *ret = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_load_connections() by using GDBusConnection directly
2019-10-06 22:50:29 +02:00
g_return_val_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable), FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_load_connections() by using GDBusConnection directly
2019-10-06 22:50:29 +02:00
ret = _nm_object_dbus_call_sync (client,
cancellable,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"LoadConnections",
g_variant_new ("(^as)",
filenames ?: NM_PTRARRAY_EMPTY (char *)),
G_VARIANT_TYPE ("(bas)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
if (!ret) {
*failures = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return FALSE;
libnm: implement nm_client_load_connections() by using GDBusConnection directly
2019-10-06 22:50:29 +02:00
}
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_load_connections() by using GDBusConnection directly
2019-10-06 22:50:29 +02:00
g_variant_get (ret,
"(b^as)",
NULL,
&failures);
return TRUE;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_load_connections_async:
* @client: the %NMClient
libnm: fix introspection annotations for nm_client_load_connections() Add the "(array zero-terminated=1)" GLib introspection annotation when the parameter is a NULL-terminated string array. https://mail.gnome.org/archives/networkmanager-list/2016-August/msg00017.html Reported-by: Petr Horacek <phoracek@redhat.com>
2016-08-04 13:38:24 +02:00
* @filenames: (array zero-terminated=1): %NULL-terminated array of filenames to load
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Requests that the remote settings service asynchronously load or reload the
* given files, adding or updating the connections described within.
*
* See nm_client_load_connections() for more details.
**/
void
nm_client_load_connections_async (NMClient *client,
char **filenames,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_load_connections_async() by using GDBusConnection directly
2019-10-06 23:16:48 +02:00
g_return_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable));
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_load_connections_async() by using GDBusConnection directly
2019-10-06 23:16:48 +02:00
_nm_object_dbus_call (client,
nm_client_load_connections_async,
cancellable,
callback,
user_data,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"LoadConnections",
g_variant_new ("(^as)",
filenames ?: NM_PTRARRAY_EMPTY (char *)),
G_VARIANT_TYPE ("(bas)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_variant_strip_dbus_error_cb);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_load_connections_finish:
* @client: the %NMClient
libnm: fix introspection annotations for nm_client_load_connections() Add the "(array zero-terminated=1)" GLib introspection annotation when the parameter is a NULL-terminated string array. https://mail.gnome.org/archives/networkmanager-list/2016-August/msg00017.html Reported-by: Petr Horacek <phoracek@redhat.com>
2016-08-04 13:38:24 +02:00
* @failures: (out) (transfer full) (array zero-terminated=1): on return, a
* %NULL-terminated array of filenames that failed to load
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
* Gets the result of an nm_client_load_connections_async() call.
* See nm_client_load_connections() for more details.
*
libnm: fix return value for nm_remote_settings_load_connections() to ignore server result nm_remote_settings_load_connections() and nm_remote_settings_load_connections_async() behave inconsistently. It's unexpected, that a FALSE return value may leave @error unset. Note that before commit 22e830f0469a ('settings/d-bus: fix boolean return value of "LoadConnections"'), the server boolean response would have been bogus anyway (at least for some versions). Unify the behavior, and ignore the boolean return value.
2019-10-06 23:19:32 +02:00
* Returns: %TRUE on success.
* Note that even in the success case, you might have individual @failures.
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
gboolean
nm_client_load_connections_finish (NMClient *client,
char ***failures,
GAsyncResult *result,
GError **error)
{
libnm: implement nm_client_load_connections_async() by using GDBusConnection directly
2019-10-06 23:16:48 +02:00
gs_unref_variant GVariant *ret = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_load_connections_async() by using GDBusConnection directly
2019-10-06 23:16:48 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_load_connections_async), FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_load_connections_async() by using GDBusConnection directly
2019-10-06 23:16:48 +02:00
ret = g_task_propagate_pointer (G_TASK (result), error);
if (!ret) {
*failures = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return FALSE;
libnm: implement nm_client_load_connections_async() by using GDBusConnection directly
2019-10-06 23:16:48 +02:00
}
g_variant_get (ret,
"(b^as)",
NULL,
&failures);
libnm: fix return value for nm_remote_settings_load_connections() to ignore server result nm_remote_settings_load_connections() and nm_remote_settings_load_connections_async() behave inconsistently. It's unexpected, that a FALSE return value may leave @error unset. Note that before commit 22e830f0469a ('settings/d-bus: fix boolean return value of "LoadConnections"'), the server boolean response would have been bogus anyway (at least for some versions). Unify the behavior, and ignore the boolean return value.
2019-10-06 23:19:32 +02:00
return TRUE;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_reload_connections:
* @client: the #NMClient
* @cancellable: a #GCancellable, or %NULL
* @error: return location for #GError
*
* Requests that the remote settings service reload all connection
* files from disk, adding, updating, and removing connections until
* the in-memory state matches the on-disk state.
*
* Return value: %TRUE on success, %FALSE on failure
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* Deprecated: 1.22, use nm_client_reload_connections_async() or GDBusConnection
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
**/
gboolean
nm_client_reload_connections (NMClient *client,
GCancellable *cancellable,
GError **error)
{
libnm: implement nm_client_reload_connections() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
gs_unref_variant GVariant *ret = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_reload_connections() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
g_return_val_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable), FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_reload_connections() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
ret = _nm_object_dbus_call_sync (client,
cancellable,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"ReloadConnections",
g_variant_new ("()"),
G_VARIANT_TYPE ("(b)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
TRUE,
error);
if (!ret)
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return FALSE;
libnm: implement nm_client_reload_connections() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
return TRUE;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_reload_connections_async:
* @client: the #NMClient
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the reload operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Requests that the remote settings service begin reloading all connection
* files from disk, adding, updating, and removing connections until the
* in-memory state matches the on-disk state.
**/
void
nm_client_reload_connections_async (NMClient *client,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_reload_connections_async() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
g_return_if_fail (!cancellable || G_IS_CANCELLABLE (cancellable));
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_reload_connections_async() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
_nm_object_dbus_call (client,
nm_client_reload_connections_async,
cancellable,
callback,
user_data,
NM_DBUS_PATH_SETTINGS,
NM_DBUS_INTERFACE_SETTINGS,
"ReloadConnections",
g_variant_new ("()"),
G_VARIANT_TYPE ("(b)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_variant_strip_dbus_error_cb);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
/**
* nm_client_reload_connections_finish:
* @client: the #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: return location for #GError
*
* Gets the result of an nm_client_reload_connections_async() call.
*
* Return value: %TRUE on success, %FALSE on failure
**/
gboolean
nm_client_reload_connections_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
libnm: implement nm_client_reload_connections_async() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
gs_unref_variant GVariant *ret = NULL;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_reload_connections_async() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_reload_connections_async), FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: implement nm_client_reload_connections_async() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
ret = g_task_propagate_pointer (G_TASK (result), error);
if (!ret)
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
return FALSE;
libnm: implement nm_client_reload_connections_async() by using GDBusConnection directly
2019-10-07 09:30:29 +02:00
return TRUE;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
/**
* nm_client_get_dns_mode:
* @client: the #NMClient
*
* Gets the current DNS processing mode.
*
* Return value: the DNS processing mode, or %NULL in case the
* value is not available.
*
* Since: 1.6
**/
const char *
nm_client_get_dns_mode (NMClient *client)
{
NMClientPrivate *priv;
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
priv = NM_CLIENT_GET_PRIVATE (client);
if (priv->dns_manager)
return nm_dns_manager_get_mode (priv->dns_manager);
else
return NULL;
}
/**
* nm_client_get_dns_rc_manager:
* @client: the #NMClient
*
* Gets the current DNS resolv.conf manager.
*
* Return value: the resolv.conf manager or %NULL in case the
* value is not available.
*
* Since: 1.6
**/
const char *
nm_client_get_dns_rc_manager (NMClient *client)
{
NMClientPrivate *priv;
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
priv = NM_CLIENT_GET_PRIVATE (client);
if (priv->dns_manager)
return nm_dns_manager_get_rc_manager (priv->dns_manager);
else
return NULL;
}
/**
* nm_client_get_dns_configuration:
* @client: a #NMClient
*
* Gets the current DNS configuration
*
* Returns: (transfer none) (element-type NMDnsEntry): a #GPtrArray
* containing #NMDnsEntry elements or %NULL in case the value is not
* available. The returned array is owned by the #NMClient object
* and should not be modified.
*
* Since: 1.6
**/
const GPtrArray *
nm_client_get_dns_configuration (NMClient *client)
{
NMClientPrivate *priv;
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
priv = NM_CLIENT_GET_PRIVATE (client);
if (priv->dns_manager)
return nm_dns_manager_get_configuration (priv->dns_manager);
else
return NULL;
}
/*****************************************************************************/
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
static void
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
subobject_notify (GObject *object,
GParamSpec *pspec,
gpointer client)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
if (!g_str_has_suffix (pspec->name, "-internal"))
g_object_notify (client, pspec->name);
}
static void
manager_device_added (NMManager *manager,
NMDevice *device,
gpointer client)
{
g_signal_emit (client, signals[DEVICE_ADDED], 0, device);
}
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
static void
manager_device_removed (NMManager *manager,
NMDevice *device,
gpointer client)
{
g_signal_emit (client, signals[DEVICE_REMOVED], 0, device);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
static void
manager_any_device_added (NMManager *manager,
NMDevice *device,
gpointer client)
{
g_signal_emit (client, signals[ANY_DEVICE_ADDED], 0, device);
}
static void
manager_any_device_removed (NMManager *manager,
NMDevice *device,
gpointer client)
{
g_signal_emit (client, signals[ANY_DEVICE_REMOVED], 0, device);
}
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
static void
manager_permission_changed (NMManager *manager,
NMClientPermission permission,
NMClientPermissionResult result,
gpointer client)
{
g_signal_emit (client, signals[PERMISSION_CHANGED], 0, permission, result);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
static void
settings_connection_added (NMRemoteSettings *manager,
NMRemoteConnection *connection,
gpointer client)
{
g_signal_emit (client, signals[CONNECTION_ADDED], 0, connection);
}
static void
settings_connection_removed (NMRemoteSettings *manager,
NMRemoteConnection *connection,
gpointer client)
{
g_signal_emit (client, signals[CONNECTION_REMOVED], 0, connection);
}
libnm/client: emit signals when active connection disappears It allows us to reliably track failures to activate a connection.
2016-07-07 11:35:19 +02:00
static void
manager_active_connection_added (NMManager *manager,
NMActiveConnection *active_connection,
gpointer client)
{
g_signal_emit (client, signals[ACTIVE_CONNECTION_ADDED], 0, active_connection);
}
static void
manager_active_connection_removed (NMManager *manager,
NMActiveConnection *active_connection,
gpointer client)
{
g_signal_emit (client, signals[ACTIVE_CONNECTION_REMOVED], 0, active_connection);
}
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
static void
dns_notify (GObject *object,
GParamSpec *pspec,
gpointer client)
{
char pname[128];
if (NM_IN_STRSET (pspec->name,
NM_DNS_MANAGER_MODE,
NM_DNS_MANAGER_RC_MANAGER,
NM_DNS_MANAGER_CONFIGURATION)) {
nm_sprintf_buf (pname, "dns-%s", pspec->name);
g_object_notify (client, pname);
}
}
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
/**
* nm_client_get_checkpoints:
* @client: a #NMClient
*
* Gets all the active checkpoints.
*
* Returns: (transfer none) (element-type NMCheckpoint): a #GPtrArray
* containing all the #NMCheckpoint. The returned array is owned by the
* #NMClient object and should not be modified.
*
* Since: 1.12
**/
const GPtrArray *
nm_client_get_checkpoints (NMClient *client)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
if (!nm_client_get_nm_running (client))
return &empty;
return nm_manager_get_checkpoints (NM_CLIENT_GET_PRIVATE (client)->manager);
}
libnm: implement nm_client_checkpoint_create() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
static void
checkpoint_create_cb (GObject *object,
GAsyncResult *result,
gpointer user_data)
{
NMClient *self;
gs_unref_object GTask *task = user_data;
gs_unref_variant GVariant *ret = NULL;
const char *checkpoint_path;
GError *error = NULL;
ret = g_dbus_connection_call_finish (G_DBUS_CONNECTION (object), result, &error);
if (!ret) {
g_dbus_error_strip_remote_error (error);
g_task_return_error (task, error);
return;
}
g_variant_get (ret,
"(&o)",
&checkpoint_path);
self = g_task_get_source_object (task);
nm_manager_wait_for_checkpoint (NM_CLIENT_GET_PRIVATE (self)->manager,
checkpoint_path,
g_steal_pointer (&task));
}
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
/**
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* nm_client_checkpoint_create:
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
* @client: the %NMClient
* @devices: (element-type NMDevice): a list of devices for which a
* checkpoint should be created.
* @rollback_timeout: the rollback timeout in seconds
* @flags: creation flags
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Creates a checkpoint of the current networking configuration
* for given interfaces. An empty @devices argument means all
* devices. If @rollback_timeout is not zero, a rollback is
* automatically performed after the given timeout.
*
* Since: 1.12
**/
void
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
nm_client_checkpoint_create (NMClient *client,
const GPtrArray *devices,
guint32 rollback_timeout,
NMCheckpointCreateFlags flags,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
{
libnm: implement nm_client_checkpoint_create() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
gs_free const char **paths = NULL;
guint i;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_checkpoint_create() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
if ( devices
&& devices->len > 0) {
paths = g_new (const char *, devices->len + 1);
for (i = 0; i < devices->len; i++)
paths[i] = nm_object_get_path (NM_OBJECT (devices->pdata[i]));
paths[i] = NULL;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
libnm: implement nm_client_checkpoint_create() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
_nm_object_dbus_call (client,
nm_client_checkpoint_create,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"CheckpointCreate",
g_variant_new ("(^aouu)",
paths ?: NM_PTRARRAY_EMPTY (const char *),
rollback_timeout,
flags),
G_VARIANT_TYPE ("(o)"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
checkpoint_create_cb);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
/**
* nm_client_checkpoint_create_finish:
* @client: the #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* Gets the result of a call to nm_client_checkpoint_create().
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
*
* Returns: (transfer full): the new #NMCheckpoint on success, %NULL on
* failure, in which case @error will be set.
*
* Since: 1.12
**/
NMCheckpoint *
nm_client_checkpoint_create_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: implement nm_client_checkpoint_create() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_checkpoint_create), NULL);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
libnm: implement nm_client_checkpoint_create() by using GDBusConnection directly
2019-10-04 17:42:32 +02:00
return g_task_propagate_pointer (G_TASK (result), error);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
/**
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* nm_client_checkpoint_destroy:
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
* @client: the %NMClient
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* @checkpoint_path: the D-Bus path for the checkpoint
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Destroys an existing checkpoint without performing a rollback.
*
* Since: 1.12
**/
void
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
nm_client_checkpoint_destroy (NMClient *client,
const char *checkpoint_path,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
g_return_if_fail (checkpoint_path && checkpoint_path[0] == '/');
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
libnm: implement nm_client_checkpoint_destroy() by using GDBusConnection directly
2019-10-06 10:52:42 +02:00
_nm_object_dbus_call (client,
nm_client_checkpoint_destroy,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"CheckpointDestroy",
g_variant_new ("(o)", checkpoint_path),
G_VARIANT_TYPE ("()"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_void_strip_dbus_error_cb);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
/**
* nm_client_checkpoint_destroy_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* Gets the result of a call to nm_client_checkpoint_destroy().
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
*
* Returns: %TRUE on success or %FALSE on failure, in which case
* @error will be set.
*
* Since: 1.12
**/
gboolean
nm_client_checkpoint_destroy_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_checkpoint_destroy() by using GDBusConnection directly
2019-10-06 10:52:42 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_checkpoint_destroy), FALSE);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
libnm: implement nm_client_checkpoint_destroy() by using GDBusConnection directly
2019-10-06 10:52:42 +02:00
return g_task_propagate_boolean (G_TASK (result), error);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
/**
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* nm_client_checkpoint_rollback:
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
* @client: the %NMClient
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* @checkpoint_path: the D-Bus path to the checkpoint
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Performs the rollback of a checkpoint before the timeout is reached.
*
* Since: 1.12
**/
void
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
nm_client_checkpoint_rollback (NMClient *client,
const char *checkpoint_path,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
g_return_if_fail (checkpoint_path && checkpoint_path[0] == '/');
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
libnm: implement nm_client_checkpoint_rollback() by using GDBusConnection directly
2019-10-06 11:06:52 +02:00
_nm_object_dbus_call (client,
nm_client_checkpoint_rollback,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"CheckpointRollback",
g_variant_new ("(o)", checkpoint_path),
G_VARIANT_TYPE ("(a{su})"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_variant_strip_dbus_error_cb);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
/**
* nm_client_checkpoint_rollback_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
* Gets the result of a call to nm_client_checkpoint_rollback().
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
*
* Returns: (transfer full) (element-type utf8 guint32): an hash table of
* devices and results. Devices are represented by their original
* D-Bus path; each result is a #NMRollbackResult.
*
* Since: 1.12
**/
GHashTable *
nm_client_checkpoint_rollback_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
libnm: implement nm_client_checkpoint_rollback() by using GDBusConnection directly
2019-10-06 11:06:52 +02:00
gs_unref_variant GVariant *ret = NULL;
gs_unref_variant GVariant *v_result = NULL;
GVariantIter iter;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
GHashTable *hash;
libnm: implement nm_client_checkpoint_rollback() by using GDBusConnection directly
2019-10-06 11:06:52 +02:00
const char *path;
guint32 r;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
libnm: implement nm_client_checkpoint_rollback() by using GDBusConnection directly
2019-10-06 11:06:52 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_checkpoint_rollback), NULL);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
libnm: implement nm_client_checkpoint_rollback() by using GDBusConnection directly
2019-10-06 11:06:52 +02:00
ret = g_task_propagate_pointer (G_TASK (result), error);
if (!ret)
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
return NULL;
libnm: implement nm_client_checkpoint_rollback() by using GDBusConnection directly
2019-10-06 11:06:52 +02:00
g_variant_get (ret,
"(@a{su})",
&v_result);
hash = g_hash_table_new_full (nm_str_hash, g_str_equal, g_free, NULL);
g_variant_iter_init (&iter, v_result);
while (g_variant_iter_next (&iter, "{&su}", &path, &r))
g_hash_table_insert (hash, g_strdup (path), GUINT_TO_POINTER (r));
return hash;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
}
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
/**
* nm_client_checkpoint_adjust_rollback_timeout:
* @client: the %NMClient
* @checkpoint_path: a D-Bus path to a checkpoint
* @add_timeout: the timeout in seconds counting from now.
* Set to zero, to disable the timeout.
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Resets the timeout for the checkpoint with path @checkpoint_path
* to @timeout_add.
*
* Since: 1.12
**/
void
nm_client_checkpoint_adjust_rollback_timeout (NMClient *client,
const char *checkpoint_path,
guint32 add_timeout,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: rework checkpoint API The libnm API fir checkpoints was only introduced with 1.11. It is not yet stable, so there is still time to adjust it. Note that this changes API/ABI of the development branch. Changes: - we only add async variants of the checkpoint functions. I believe that synchronous D-Bus methods are fundamentally flawed, because they mess up the ordering of events. Rename the async functions by removing the "_async" suffix. This matches glib style, for which the async form is also not specially marked. - for function that refere to a particular checkpoint (rollback and destroy), accept the D-Bus path as string, instead of an NMCheckpoint instance. This form is more flexible, because it allows to use the function without having a NMCheckpoint instance at hand. On the other hand, if one has a NMCheckpoint instance, he can trivially obtain the path to make the call.
2018-04-04 13:33:53 +02:00
g_return_if_fail (checkpoint_path && checkpoint_path[0] == '/');
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
libnm: implement nm_client_checkpoint_adjust_rollback_timeout() by using GDBusConnection directly
2019-10-06 11:16:10 +02:00
_nm_object_dbus_call (client,
nm_client_checkpoint_adjust_rollback_timeout,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"CheckpointAdjustRollbackTimeout",
g_variant_new ("(ou)",
checkpoint_path,
add_timeout),
G_VARIANT_TYPE ("()"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_void_strip_dbus_error_cb);
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
}
/**
* nm_client_checkpoint_adjust_rollback_timeout_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
* Gets the result of a call to nm_client_checkpoint_adjust_rollback_timeout().
*
* Returns: %TRUE on success or %FALSE on failure.
*
* Since: 1.12
**/
gboolean
nm_client_checkpoint_adjust_rollback_timeout_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_checkpoint_adjust_rollback_timeout() by using GDBusConnection directly
2019-10-06 11:16:10 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_checkpoint_adjust_rollback_timeout), FALSE);
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
libnm: implement nm_client_checkpoint_adjust_rollback_timeout() by using GDBusConnection directly
2019-10-06 11:16:10 +02:00
return g_task_propagate_boolean (G_TASK (result), error);
checkpoint: allow resetting the rollback timeout via D-Bus This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
2018-03-28 08:09:56 +02:00
}
libnm: add nm_client_reload() Introduce libnm API to reload NM configuration through the Reload() D-Bus method.
2019-09-05 15:19:33 +02:00
/**
* nm_client_reload:
* @client: the %NMClient
* @flags: flags indicating what to reload.
* @cancellable: a #GCancellable, or %NULL
* @callback: (scope async): callback to be called when the add operation completes
* @user_data: (closure): caller-specific data passed to @callback
*
* Reload NetworkManager's configuration and perform certain updates, like
* flushing caches or rewriting external state to disk. This is similar to
* sending SIGHUP to NetworkManager but it allows for more fine-grained control
* over what to reload (see @flags). It also allows non-root access via
* PolicyKit and contrary to signals it is synchronous.
*
* Since: 1.22
**/
void
nm_client_reload (NMClient *client,
NMManagerReloadFlags flags,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
g_return_if_fail (NM_IS_CLIENT (client));
libnm: implement nm_client_reload() by using GDBusConnection directly
2019-10-06 11:26:09 +02:00
_nm_object_dbus_call (client,
nm_client_reload,
cancellable,
callback,
user_data,
NM_DBUS_PATH,
NM_DBUS_INTERFACE,
"Reload",
g_variant_new ("(u)", (guint32) flags),
G_VARIANT_TYPE ("()"),
G_DBUS_CALL_FLAGS_NONE,
NM_DBUS_DEFAULT_TIMEOUT_MSEC,
nm_dbus_connection_call_finish_void_strip_dbus_error_cb);
libnm: add nm_client_reload() Introduce libnm API to reload NM configuration through the Reload() D-Bus method.
2019-09-05 15:19:33 +02:00
}
/**
* nm_client_reload_finish:
* @client: an #NMClient
* @result: the result passed to the #GAsyncReadyCallback
* @error: location for a #GError, or %NULL
*
* Gets the result of a call to nm_client_reload().
*
* Returns: %TRUE on success or %FALSE on failure.
*
* Since: 1.22
**/
gboolean
nm_client_reload_finish (NMClient *client,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail (NM_IS_CLIENT (client), FALSE);
libnm: implement nm_client_reload() by using GDBusConnection directly
2019-10-06 11:26:09 +02:00
g_return_val_if_fail (nm_g_task_is_valid (result, client, nm_client_reload), FALSE);
libnm: add nm_client_reload() Introduce libnm API to reload NM configuration through the Reload() D-Bus method.
2019-09-05 15:19:33 +02:00
libnm: implement nm_client_reload() by using GDBusConnection directly
2019-10-06 11:26:09 +02:00
return g_task_propagate_boolean (G_TASK (result), error);
libnm: add nm_client_reload() Introduce libnm API to reload NM configuration through the Reload() D-Bus method.
2019-09-05 15:19:33 +02:00
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
/****************************************************************/
/* Object Initialization */
/****************************************************************/
static GType
proxy_type (GDBusObjectManagerClient *manager,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char *object_path,
const char *interface_name,
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
gpointer user_data)
{
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
/* ObjectManager asks us for an object proxy. Unfortunately, we can't
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
* decide that by interface name and GDBusObjectManager doesn't allow
* us to look at the known interface list. Thus we need to create a
* generic GDBusObject and only couple a NMObject subclass later. */
if (!interface_name)
return G_TYPE_DBUS_OBJECT_PROXY;
/* An interface proxy */
if (strcmp (interface_name, NM_DBUS_INTERFACE) == 0)
return NMDBUS_TYPE_MANAGER_PROXY;
else if (strcmp (interface_name, NM_DBUS_INTERFACE_DEVICE_WIRELESS) == 0)
return NMDBUS_TYPE_DEVICE_WIFI_PROXY;
wifi-p2p: rename Wi-Fi P2P After renaming the files, also rename all the content to follow the "Wi-Fi P2P" naming scheme.
2019-01-28 15:21:59 +01:00
else if (strcmp (interface_name, NM_DBUS_INTERFACE_DEVICE_WIFI_P2P) == 0)
return NMDBUS_TYPE_DEVICE_WIFI_P2P_PROXY;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (interface_name, NM_DBUS_INTERFACE_DEVICE) == 0)
return NMDBUS_TYPE_DEVICE_PROXY;
else if (strcmp (interface_name, NM_DBUS_INTERFACE_SETTINGS_CONNECTION) == 0)
return NMDBUS_TYPE_SETTINGS_CONNECTION_PROXY;
else if (strcmp (interface_name, NM_DBUS_INTERFACE_SETTINGS) == 0)
return NMDBUS_TYPE_SETTINGS_PROXY;
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
else if (strcmp (interface_name, NM_DBUS_INTERFACE_DNS_MANAGER) == 0)
return NMDBUS_TYPE_DNS_MANAGER_PROXY;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (interface_name, NM_DBUS_INTERFACE_VPN_CONNECTION) == 0)
return NMDBUS_TYPE_VPN_CONNECTION_PROXY;
libnm/active-connection: track reason for state changes 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.
2017-03-05 17:20:27 +01:00
else if (strcmp (interface_name, NM_DBUS_INTERFACE_ACTIVE_CONNECTION) == 0)
return NMDBUS_TYPE_ACTIVE_CONNECTION_PROXY;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
/* Use a generic D-Bus Proxy whenever we can. The typed GDBusProxy
* subclasses actually use quite some memory, so they're better avoided. */
return G_TYPE_DBUS_PROXY;
}
static NMObject *
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
obj_nm_for_gdbus_object (NMClient *self, GDBusObject *object, GDBusObjectManager *object_manager)
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
{
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
NMClientPrivate *priv;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
GList *interfaces;
GList *l;
GType type = G_TYPE_INVALID;
NMObject *obj_nm;
g_return_val_if_fail (G_IS_DBUS_OBJECT_PROXY (object), NULL);
interfaces = g_dbus_object_get_interfaces (object);
for (l = interfaces; l; l = l->next) {
GDBusProxy *proxy = G_DBUS_PROXY (l->data);
const char *ifname = g_dbus_proxy_get_interface_name (proxy);
/* This is a performance/scalability hack. It makes sense to call it
* from here, since this is in the common object creation path. */
_nm_dbus_proxy_replace_match (proxy);
if (strcmp (ifname, NM_DBUS_INTERFACE) == 0)
type = NM_TYPE_MANAGER;
else if (strcmp (ifname, NM_DBUS_INTERFACE_ACCESS_POINT) == 0)
type = NM_TYPE_ACCESS_POINT;
else if (strcmp (ifname, NM_DBUS_INTERFACE_ACTIVE_CONNECTION) == 0 && type != NM_TYPE_VPN_CONNECTION)
type = NM_TYPE_ACTIVE_CONNECTION;
libnm: add support form 6LoWPAN devices
2018-05-22 16:45:05 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_6LOWPAN) == 0)
type = NM_TYPE_DEVICE_6LOWPAN;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_ADSL) == 0)
type = NM_TYPE_DEVICE_ADSL;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_BOND) == 0)
type = NM_TYPE_DEVICE_BOND;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_BRIDGE) == 0)
type = NM_TYPE_DEVICE_BRIDGE;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_BLUETOOTH) == 0)
type = NM_TYPE_DEVICE_BT;
core: add support for dummy devices 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.
2017-01-31 14:14:33 +01:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_DUMMY) == 0)
type = NM_TYPE_DEVICE_DUMMY;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_WIRED) == 0)
type = NM_TYPE_DEVICE_ETHERNET;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_GENERIC) == 0)
type = NM_TYPE_DEVICE_GENERIC;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_INFINIBAND) == 0)
type = NM_TYPE_DEVICE_INFINIBAND;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_IP_TUNNEL) == 0)
type = NM_TYPE_DEVICE_IP_TUNNEL;
core,libnm: introduce NMDeviceMacsec At the moment the device only exposes the current link status, but cannot create new links.
2016-06-30 18:20:22 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_MACSEC) == 0)
type = NM_TYPE_DEVICE_MACSEC;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_MACVLAN) == 0)
type = NM_TYPE_DEVICE_MACVLAN;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_MODEM) == 0)
type = NM_TYPE_DEVICE_MODEM;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_OLPC_MESH) == 0)
type = NM_TYPE_DEVICE_OLPC_MESH;
libnm: add support for ovs-interface devices
2017-10-10 11:04:32 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_OVS_INTERFACE) == 0)
type = NM_TYPE_DEVICE_OVS_INTERFACE;
libnm: add support for ovs-port devices
2017-10-10 11:04:32 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_OVS_PORT) == 0)
type = NM_TYPE_DEVICE_OVS_PORT;
libnm: add support for ovs-bridge devices
2017-10-10 11:04:32 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_OVS_BRIDGE) == 0)
type = NM_TYPE_DEVICE_OVS_BRIDGE;
wifi-p2p: rename Wi-Fi P2P After renaming the files, also rename all the content to follow the "Wi-Fi P2P" naming scheme.
2019-01-28 15:21:59 +01:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_WIFI_P2P) == 0)
type = NM_TYPE_DEVICE_WIFI_P2P;
device: add NMDevicePPP The new device type represents a PPP interface, and will implement the activation of new-style PPPoE connections, i.e. the ones that don't claim the parent device.
2017-06-06 15:55:08 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_PPP) == 0)
type = NM_TYPE_DEVICE_PPP;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_TEAM) == 0)
type = NM_TYPE_DEVICE_TEAM;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_TUN) == 0)
type = NM_TYPE_DEVICE_TUN;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_VLAN) == 0)
type = NM_TYPE_DEVICE_VLAN;
libnm: add support for WPAN devices
2018-03-09 17:19:36 +01:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_WPAN) == 0)
type = NM_TYPE_DEVICE_WPAN;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_VXLAN) == 0)
type = NM_TYPE_DEVICE_VXLAN;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_WIRELESS) == 0)
type = NM_TYPE_DEVICE_WIFI;
libnm: introduce NMDeviceWireGuard
2018-03-13 13:42:38 +00:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DEVICE_WIREGUARD) == 0)
type = NM_TYPE_DEVICE_WIREGUARD;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DHCP4_CONFIG) == 0)
type = NM_TYPE_DHCP4_CONFIG;
else if (strcmp (ifname, NM_DBUS_INTERFACE_DHCP6_CONFIG) == 0)
type = NM_TYPE_DHCP6_CONFIG;
else if (strcmp (ifname, NM_DBUS_INTERFACE_IP4_CONFIG) == 0)
type = NM_TYPE_IP4_CONFIG;
else if (strcmp (ifname, NM_DBUS_INTERFACE_IP6_CONFIG) == 0)
type = NM_TYPE_IP6_CONFIG;
wifi-p2p: rename Wi-Fi P2P After renaming the files, also rename all the content to follow the "Wi-Fi P2P" naming scheme.
2019-01-28 15:21:59 +01:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_WIFI_P2P_PEER) == 0)
type = NM_TYPE_WIFI_P2P_PEER;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_SETTINGS_CONNECTION) == 0)
type = NM_TYPE_REMOTE_CONNECTION;
else if (strcmp (ifname, NM_DBUS_INTERFACE_SETTINGS) == 0)
type = NM_TYPE_REMOTE_SETTINGS;
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_DNS_MANAGER) == 0)
type = NM_TYPE_DNS_MANAGER;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_VPN_CONNECTION) == 0)
type = NM_TYPE_VPN_CONNECTION;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
else if (strcmp (ifname, NM_DBUS_INTERFACE_CHECKPOINT) == 0)
type = NM_TYPE_CHECKPOINT;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (type != G_TYPE_INVALID)
break;
}
g_list_free_full (interfaces, g_object_unref);
if (type == G_TYPE_INVALID)
return NULL;
obj_nm = g_object_new (type,
NM_OBJECT_DBUS_OBJECT, object,
NM_OBJECT_DBUS_OBJECT_MANAGER, object_manager,
NULL);
libnm: fix showing UDEV properties for device https://mail.gnome.org/archives/networkmanager-list/2017-March/msg00065.html Fixes: c7ccdf5fc893fd41f23349f298bf2c3ea383487a (cherry picked from commit c06308a10cb8e2192e5b8128776bc13f4450cb40)
2017-03-29 09:37:58 +02:00
if (NM_IS_DEVICE (obj_nm)) {
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
priv = NM_CLIENT_GET_PRIVATE (self);
clients/tests: add python test script for nmcli tests Add a test which runs nmcli against our stub NetworkManager service and compares the output. The output formats of nmcli are complicated and not easily understood. For example how --mode tabular|multiline interacts with selecting output-fields (--fields) and output modes ([default]|--terse|--pretty). Also, there are things like `nmcli connection show --order $FIELD_SPEC`. We need unit tests to ensure that we don't change the output accidentally.
2018-05-04 09:02:53 +02:00
if (G_UNLIKELY (!priv->udev_inited)) {
priv->udev_inited = TRUE;
/* for testing, we don't want to use udev in libnm. */
if (!nm_streq0 (g_getenv ("LIBNM_USE_NO_UDEV"), "1"))
priv->udev = udev_new ();
}
if (priv->udev)
_nm_device_set_udev (NM_DEVICE (obj_nm), priv->udev);
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_object_set_qdata_full (G_OBJECT (object), _nm_object_obj_nm_quark (),
obj_nm, g_object_unref);
return obj_nm;
}
static void
obj_nm_inited (GObject *object, GAsyncResult *result, gpointer user_data)
{
if (!g_async_initable_init_finish (G_ASYNC_INITABLE (object), result, NULL)) {
/* This is a can-not-happen situation, the NMObject subclasses are not
* supposed to fail initialization. */
g_warn_if_reached ();
}
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
object_added (GDBusObjectManager *object_manager, GDBusObject *object, gpointer user_data)
{
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
NMClient *client = user_data;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
NMObject *obj_nm;
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
obj_nm = obj_nm_for_gdbus_object (client, object, object_manager);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (obj_nm) {
g_async_initable_init_async (G_ASYNC_INITABLE (obj_nm),
G_PRIORITY_DEFAULT, NULL,
obj_nm_inited, NULL);
}
}
static void
object_removed (GDBusObjectManager *object_manager, GDBusObject *object, gpointer user_data)
{
g_object_set_qdata (G_OBJECT (object), _nm_object_obj_nm_quark (), NULL);
}
static gboolean
objects_created (NMClient *client, GDBusObjectManager *object_manager, GError **error)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (client);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
gs_unref_object GDBusObject *manager = NULL;
gs_unref_object GDBusObject *settings = NULL;
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
gs_unref_object GDBusObject *dns_manager = NULL;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
NMObject *obj_nm;
GList *objects, *iter;
/* First just ensure all the NMObjects for known GDBusObjects exist. */
objects = g_dbus_object_manager_get_objects (object_manager);
for (iter = objects; iter; iter = iter->next)
libnm/udev: cache and reuse udev instance for NMDevice 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.
2017-03-20 12:27:17 +01:00
obj_nm_for_gdbus_object (client, iter->data, object_manager);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_list_free_full (objects, g_object_unref);
manager = g_dbus_object_manager_get_object (object_manager, NM_DBUS_PATH);
if (!manager) {
g_set_error_literal (error,
NM_CLIENT_ERROR,
NM_CLIENT_ERROR_MANAGER_NOT_RUNNING,
"Manager object not found");
return FALSE;
}
obj_nm = g_object_get_qdata (G_OBJECT (manager), _nm_object_obj_nm_quark ());
if (!obj_nm) {
g_set_error_literal (error,
NM_CLIENT_ERROR,
NM_CLIENT_ERROR_MANAGER_NOT_RUNNING,
"Manager object lacks the proper interface");
return FALSE;
}
priv->manager = NM_MANAGER (g_object_ref (obj_nm));
libnm: remove redundant NM name watching code NMClient was watching to see whether NetworkManager was running, but its parent class NMObject was already doing that anyway, so NMClient doesn't need to do it itself. This also requires making NMClient:init_async() wait for NMObject's init_async() code to finish before calling GetPermissions, rather than running the two in parallel like before (since we don't know if NM is running or not until after NMObject's init_async() returns). This is probably more correct anyway in terms of inheritance, and it's not as much slower than the original code as it sounds, since previously we were calling NameHasOwner twice (in serial) anyway.
2014-07-14 12:17:59 -04:00
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
g_signal_connect (priv->manager, "notify",
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
G_CALLBACK (subobject_notify), client);
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
g_signal_connect (priv->manager, "device-added",
G_CALLBACK (manager_device_added), client);
g_signal_connect (priv->manager, "device-removed",
G_CALLBACK (manager_device_removed), client);
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
g_signal_connect (priv->manager, "any-device-added",
G_CALLBACK (manager_any_device_added), client);
g_signal_connect (priv->manager, "any-device-removed",
G_CALLBACK (manager_any_device_removed), client);
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
g_signal_connect (priv->manager, "permission-changed",
G_CALLBACK (manager_permission_changed), client);
libnm/client: emit signals when active connection disappears It allows us to reliably track failures to activate a connection.
2016-07-07 11:35:19 +02:00
g_signal_connect (priv->manager, "active-connection-added",
G_CALLBACK (manager_active_connection_added), client);
g_signal_connect (priv->manager, "active-connection-removed",
G_CALLBACK (manager_active_connection_removed), client);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
settings = g_dbus_object_manager_get_object (object_manager, NM_DBUS_PATH_SETTINGS);
if (!settings) {
g_set_error_literal (error,
NM_CLIENT_ERROR,
NM_CLIENT_ERROR_MANAGER_NOT_RUNNING,
"Settings object not found");
return FALSE;
}
obj_nm = g_object_get_qdata (G_OBJECT (settings), _nm_object_obj_nm_quark ());
if (!obj_nm) {
g_set_error_literal (error,
NM_CLIENT_ERROR,
NM_CLIENT_ERROR_MANAGER_NOT_RUNNING,
"Settings object lacks the proper interface");
return FALSE;
}
priv->settings = NM_REMOTE_SETTINGS (g_object_ref (obj_nm));
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
g_signal_connect (priv->settings, "notify",
G_CALLBACK (subobject_notify), client);
g_signal_connect (priv->settings, "connection-added",
G_CALLBACK (settings_connection_added), client);
g_signal_connect (priv->settings, "connection-removed",
G_CALLBACK (settings_connection_removed), client);
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
dns_manager = g_dbus_object_manager_get_object (object_manager, NM_DBUS_PATH_DNS_MANAGER);
if (dns_manager) {
obj_nm = g_object_get_qdata (G_OBJECT (dns_manager), _nm_object_obj_nm_quark ());
if (!obj_nm) {
g_set_error_literal (error,
NM_CLIENT_ERROR,
NM_CLIENT_ERROR_MANAGER_NOT_RUNNING,
"DNS manager object lacks the proper interface");
return FALSE;
}
priv->dns_manager = NM_DNS_MANAGER (g_object_ref (obj_nm));
g_signal_connect (priv->dns_manager, "notify",
G_CALLBACK (dns_notify), client);
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
/* The handlers don't really use the client instance. However
* it makes it convenient to unhook them by data. */
g_signal_connect (object_manager, "object-added",
G_CALLBACK (object_added), client);
g_signal_connect (object_manager, "object-removed",
G_CALLBACK (object_removed), client);
return TRUE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
/* Synchronous initialization. */
static void name_owner_changed (GObject *object, GParamSpec *pspec, gpointer user_data);
libnm: refactor name-owner check for object-manager
2017-06-21 15:57:07 +02:00
static gboolean
_om_has_name_owner (GDBusObjectManager *object_manager)
{
gs_free char *name_owner = NULL;
nm_assert (G_IS_DBUS_OBJECT_MANAGER_CLIENT (object_manager));
name_owner = g_dbus_object_manager_client_get_name_owner (G_DBUS_OBJECT_MANAGER_CLIENT (object_manager));
return !!name_owner;
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
/* Asynchronous initialization. */
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void
init_async_complete (NMClientInitData *init_data)
{
libnm: move check for pending_init to init_async_complete()
2017-06-21 15:34:34 +02:00
if (init_data->pending_init > 0)
return;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_simple_async_result_complete (init_data->result);
g_object_unref (init_data->result);
libnm: port to GDBus Port libnm-core/libnm to GDBus. The NetworkManager daemon continues to use dbus-glib; the previously-added connection hash/variant conversion methods are now moved to NetworkManagerUtils (along with a few other utilities that are now only needed by the daemon code).
2014-09-10 13:51:53 -04:00
g_clear_object (&init_data->cancellable);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_slice_free (NMClientInitData, init_data);
}
static void
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
async_inited_obj_nm (GObject *object, GAsyncResult *result, gpointer user_data)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
NMClientInitData *init_data = user_data;
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
GError *error = NULL;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: assert in async_inited_obj_nm() for existing pending_init count
2017-06-21 15:20:19 +02:00
nm_assert (init_data && init_data->pending_init > 0);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
if (!g_async_initable_init_finish (G_ASYNC_INITABLE (object), result, &error))
g_simple_async_result_take_error (init_data->result, error);
libnm: assert in async_inited_obj_nm() for existing pending_init count
2017-06-21 15:20:19 +02:00
init_data->pending_init--;
libnm: move check for pending_init to init_async_complete()
2017-06-21 15:34:34 +02:00
init_async_complete (init_data);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
}
static void
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
init_async (GAsyncInitable *initable, int io_priority,
GCancellable *cancellable, GAsyncReadyCallback callback,
gpointer user_data);
static void
unhook_om (NMClient *self)
{
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (self);
GList *objects, *iter;
if (priv->manager) {
const GPtrArray *active_connections;
const GPtrArray *devices;
int i;
active_connections = nm_manager_get_active_connections (priv->manager);
for (i = 0; i < active_connections->len; i++)
g_signal_emit (self, signals[ACTIVE_CONNECTION_REMOVED], 0, active_connections->pdata[i]);
devices = nm_manager_get_all_devices (priv->manager);
for (i = 0; i < devices->len; i++)
g_signal_emit (self, signals[DEVICE_REMOVED], 0, devices->pdata[i]);
g_signal_handlers_disconnect_by_data (priv->manager, self);
g_clear_object (&priv->manager);
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
_notify (self, PROP_ACTIVE_CONNECTIONS);
_notify (self, PROP_NM_RUNNING);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
}
if (priv->settings) {
const GPtrArray *connections;
guint i;
connections = nm_remote_settings_get_connections (priv->settings);
for (i = 0; i < connections->len; i++)
g_signal_emit (self, signals[CONNECTION_REMOVED], 0, connections->pdata[i]);
g_signal_handlers_disconnect_by_data (priv->settings, self);
g_clear_object (&priv->settings);
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
_notify (self, PROP_CONNECTIONS);
_notify (self, PROP_HOSTNAME);
_notify (self, PROP_CAN_MODIFY);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
}
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
if (priv->dns_manager) {
g_signal_handlers_disconnect_by_data (priv->dns_manager, self);
g_clear_object (&priv->dns_manager);
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
objects = g_dbus_object_manager_get_objects (priv->object_manager);
for (iter = objects; iter; iter = iter->next)
g_object_set_qdata (iter->data, _nm_object_obj_nm_quark (), NULL);
g_list_free_full (objects, g_object_unref);
}
static void
new_object_manager (GObject *source_object, GAsyncResult *res, gpointer user_data)
{
libnm: fix getting self pointer in NMClient's new_object_manager()
2017-06-20 14:20:38 +02:00
NMClient *self = NM_CLIENT (user_data);
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (self);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_clear_object (&priv->new_object_manager_cancellable);
libnm: avoid g_object_notify() in favor of _notify() This looks up the GParamSpec from the obj_properties and is thus more efficient. Also, the generated _notify() function has the proper argument type and is thus generally preferable.
2019-10-17 10:47:29 +02:00
_notify (user_data, PROP_NM_RUNNING);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
}
Revert "libnm: don't use async constructor for GDBusObjectManager" 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 529d620a59f42e3f06bd4e7de5c817f175803c0d.
2017-06-28 18:42:04 +02:00
static void
got_object_manager (GObject *object, GAsyncResult *result, gpointer user_data)
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
{
NMClientInitData *init_data = user_data;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
NMClient *client;
NMClientPrivate *priv;
GList *objects, *iter;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
GError *error = NULL;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
GDBusObjectManager *object_manager;
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
object_manager = (gpointer) g_async_initable_new_finish (G_ASYNC_INITABLE (object), result, &error);
Revert "libnm: refactor error handling in got_object_manager()" This reverts commit c5370ea71a6c0686d5bffb7039d9053335384f20.
2017-06-28 18:41:57 +02:00
if (object_manager == NULL) {
g_simple_async_result_take_error (init_data->result, error);
init_async_complete (init_data);
Revert "libnm: don't use async constructor for GDBusObjectManager" 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 529d620a59f42e3f06bd4e7de5c817f175803c0d.
2017-06-28 18:42:04 +02:00
return;
Revert "libnm: refactor error handling in got_object_manager()" This reverts commit c5370ea71a6c0686d5bffb7039d9053335384f20.
2017-06-28 18:41:57 +02:00
}
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
nm_assert (G_IS_DBUS_OBJECT_MANAGER_CLIENT (object_manager));
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
client = init_data->client;
priv = NM_CLIENT_GET_PRIVATE (client);
priv->object_manager = object_manager;
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
if (!priv->dbus_connection)
priv->dbus_connection = g_object_ref (g_dbus_object_manager_client_get_connection (G_DBUS_OBJECT_MANAGER_CLIENT (priv->object_manager)));
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
libnm: refactor name-owner check for object-manager
2017-06-21 15:57:07 +02:00
if (_om_has_name_owner (priv->object_manager)) {
Revert "libnm: refactor error handling in got_object_manager()" This reverts commit c5370ea71a6c0686d5bffb7039d9053335384f20.
2017-06-28 18:41:57 +02:00
if (!objects_created (client, priv->object_manager, &error)) {
g_simple_async_result_take_error (init_data->result, error);
init_async_complete (init_data);
Revert "libnm: don't use async constructor for GDBusObjectManager" 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 529d620a59f42e3f06bd4e7de5c817f175803c0d.
2017-06-28 18:42:04 +02:00
return;
Revert "libnm: refactor error handling in got_object_manager()" This reverts commit c5370ea71a6c0686d5bffb7039d9053335384f20.
2017-06-28 18:41:57 +02:00
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
objects = g_dbus_object_manager_get_objects (priv->object_manager);
for (iter = objects; iter; iter = iter->next) {
NMObject *obj_nm;
obj_nm = g_object_get_qdata (iter->data, _nm_object_obj_nm_quark ());
if (!obj_nm)
continue;
init_data->pending_init++;
g_async_initable_init_async (G_ASYNC_INITABLE (obj_nm),
G_PRIORITY_DEFAULT, init_data->cancellable,
async_inited_obj_nm, init_data);
}
g_list_free_full (objects, g_object_unref);
libnm: fix leaking init_data in got_object_manager() Only happens if there are no objects, which would be very unusual.
2017-06-21 15:32:23 +02:00
}
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
libnm: move check for pending_init to init_async_complete()
2017-06-21 15:34:34 +02:00
init_async_complete (init_data);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_signal_connect (priv->object_manager, "notify::name-owner",
G_CALLBACK (name_owner_changed), client);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
static void
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
prepare_object_manager (NMClient *client,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (client);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
NMClientInitData *init_data;
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
GBusType bus_type = G_BUS_TYPE_NONE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
init_data = g_slice_new0 (NMClientInitData);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
init_data->client = client;
libnm: port to GDBus Port libnm-core/libnm to GDBus. The NetworkManager daemon continues to use dbus-glib; the previously-added connection hash/variant conversion methods are now moved to NetworkManagerUtils (along with a few other utilities that are now only needed by the daemon code).
2014-09-10 13:51:53 -04:00
init_data->cancellable = cancellable ? g_object_ref (cancellable) : NULL;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
init_data->result = g_simple_async_result_new (G_OBJECT (client), callback,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
user_data, init_async);
Add calls to g_simple_async_result_set_check_cancellable If an operation is cancelled through the GCancellable, then the idiom is that the operation is always cancelled, even if it has finished successfully. To ensure this is the case, add calls to g_simple_async_result_set_check_cancellable everywhere. Without this, e.g. gnome-control-center will crash when switching away from the power panel quickly, as the NMClient creation finishes asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to ensure it doesn't access the now invalid user_data parameter. https://bugzilla.gnome.org/show_bug.cgi?id=794088
2018-03-05 16:02:24 +01:00
if (cancellable)
g_simple_async_result_set_check_cancellable (init_data->result, cancellable);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_simple_async_result_set_op_res_gboolean (init_data->result, TRUE);
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
if (!priv->dbus_connection)
bus_type = _nm_dbus_bus_type ();
g_async_initable_new_async (G_TYPE_DBUS_OBJECT_MANAGER_CLIENT,
G_PRIORITY_DEFAULT,
init_data->cancellable,
got_object_manager,
init_data,
"connection", priv->dbus_connection,
"bus-type", bus_type,
"flags", G_DBUS_OBJECT_MANAGER_CLIENT_FLAGS_DO_NOT_AUTO_START,
"name", "org.freedesktop.NetworkManager",
"object-path", "/org/freedesktop",
"get-proxy-type-func", proxy_type,
"get-proxy-type-user-data", NULL,
"get-proxy-type-destroy-notify", NULL,
NULL);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
}
static void
name_owner_changed (GObject *object, GParamSpec *pspec, gpointer user_data)
{
NMClient *self = user_data;
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (self);
GDBusObjectManager *object_manager = G_DBUS_OBJECT_MANAGER (object);
libnm: clear NMClientPrivate.object_manager in name_owner_changed() Don't leave dangling pointers.
2017-06-20 14:13:16 +02:00
nm_assert (object_manager == priv->object_manager);
libnm: refactor name-owner check for object-manager
2017-06-21 15:57:07 +02:00
if (_om_has_name_owner (object_manager)) {
libnm: disconnect signal handlers from old object-manager When NM is restarted and a new object-manager is created, ensure that signal handlers are disconnected from the old one. Fixes the following: assertion failed: (object_manager == priv->object_manager) #0 __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 __GI_abort () at abort.c:90 #2 g_assertion_message (domain=domain@entry=0x7fcac0b845ff "libnm", file=file@entry=0x7fcac0b84c95 "libnm/nm-client.c", line=line@entry=2506, func=func@entry=0x7fcac0b863a0 <__func__.34881> "name_owner_changed", message=message@entry=0x7fcac20b05f0 "assertion failed: (object_manager == priv->object_manager)") at gtestutils.c:2429 #3 g_assertion_message_expr (domain=domain@entry=0x7fcac0b845ff "libnm", file=file@entry=0x7fcac0b84c95 "libnm/nm-client.c", line=line@entry=2506, func=func@entry=0x7fcac0b863a0 <__func__.34881> "name_owner_changed", expr=expr@entry=0x7fcac0b856a0 "object_manager == priv->object_manager") at gtestutils.c:2444 #4 name_owner_changed (object=<optimized out>, pspec=<optimized out>, user_data=0x7fcac204e480) at libnm/nm-client.c:2506 #8 <emit signal notify:name-owner on instance 0x7fcac2053c60 [GDBusObjectManagerClient]> (instance=instance@entry=0x7fcac2053c60, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3439 #5 g_closure_invoke (closure=0x7fcac20af390, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7ffde58d9ec0, invocation_hint=invocation_hint@entry=0x7ffde58d9e60) at gclosure.c:801 #6 signal_emit_unlocked_R (node=node@entry=0x7fcac2052090, detail=detail@entry=185, instance=instance@entry=0x7fcac2053c60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffde58d9ec0) at gsignal.c:3627 #7 g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffde58da050) at gsignal.c:3383 #9 g_object_dispatch_properties_changed (object=0x7fcac2053c60 [GDBusObjectManagerClient], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1061 #10 g_object_notify (pspec=<optimized out>, object=0x7fcac2053c60 [GDBusObjectManagerClient]) at gobject.c:1155 #11 g_object_notify (object=object@entry=0x7fcac2053c60 [GDBusObjectManagerClient], property_name=property_name@entry=0x7fcabe9d2b29 "name-owner") at gobject.c:1202 #12 on_notify_g_name_owner (object=<optimized out>, pspec=<optimized out>, user_data=0x7fcac2053c60) at gdbusobjectmanagerclient.c:1262 #16 <emit signal notify:g-name-owner on instance 0x7fcaa8004440 [GDBusProxy]> (instance=instance@entry=0x7fcaa8004440, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3439 #13 g_closure_invoke (closure=0x7fcaa80194f0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7ffde58da370, invocation_hint=invocation_hint@entry=0x7ffde58da310) at gclosure.c:801 #14 signal_emit_unlocked_R (node=node@entry=0x7fcac2052090, detail=detail@entry=299, instance=instance@entry=0x7fcaa8004440, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffde58da370) at gsignal.c:3627 #15 g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffde58da500) at gsignal.c:3383 #17 g_object_dispatch_properties_changed (object=0x7fcaa8004440 [GDBusProxy], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1061 #18 g_object_notify (pspec=<optimized out>, object=0x7fcaa8004440 [GDBusProxy]) at gobject.c:1155 #19 g_object_notify (object=object@entry=0x7fcaa8004440 [GDBusProxy], property_name=property_name@entry=0x7fcabe9d2b27 "g-name-owner") at gobject.c:1202 #20 on_name_owner_changed (connection=<optimized out>, sender_name=<optimized out>, object_path=<optimized out>, interface_name=<optimized out>, signal_name=<optimized out>, parameters=<optimized out>, user_data=0x7fcaa8015b50) at gdbusproxy.c:1353 #21 emit_signal_instance_in_idle_cb (data=0x7fcaa40ff400) at gdbusconnection.c:3701 #22 g_main_context_dispatch (context=0x7fcac204eea0) at gmain.c:3152 #23 g_main_context_dispatch (context=context@entry=0x7fcac204eea0) at gmain.c:3767 #24 g_main_context_iterate (context=context@entry=0x7fcac204eea0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838 #25 g_main_context_iteration (context=0x7fcac204eea0, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3899 #26 nmc_readline_helper (prompt=prompt@entry=0x7fcac2087f60 "The connection is not saved. Do you really want to quit? (yes/no) [no] ") at clients/cli/common.c:986 #27 nmc_readline (prompt_fmt=<optimized out>) at clients/cli/common.c:1055 #28 confirm_quit () at clients/cli/connections.c:6459 #29 do_connection_edit (connection_type=<optimized out>, connection=0x7fcac208eca0, nmc=0x7fcac12a3a60 <nm_cli>) at clients/cli/connections.c:7611 #30 do_connection_edit (nmc=0x7fcac12a3a60 <nm_cli>, argc=1, argv=0x7ffde58db0b0) at clients/cli/connections.c:7948 #31 call_cmd (nmc=0x7fcac12a3a60 <nm_cli>, simple=0x7fcac2052490 [GSimpleAsyncResult], cmd=0x7fcac1291ae0 <connection_cmds+128>, argc=2, argv=0x7ffde58db0a8) at clients/cli/common.c:1315 #32 got_client (source_object=<optimized out>, res=<optimized out>, user_data=0x7fcac2051830) at clients/cli/common.c:1297 #33 g_simple_async_result_complete (simple=0x7fcac2052500 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801 #34 client_inited (source=0x7fcac204e480 [NMClient], result=0x7fcac20565f0, user_data=0x7fcac2052500) at libnm/nm-client.c:1839 #35 g_simple_async_result_complete (simple=0x7fcac20565f0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801 #36 init_async_complete (init_data=init_data@entry=0x7fcac2046820) at libnm/nm-client.c:2339 #37 async_inited_obj_nm (init_data=0x7fcac2046820) at libnm/nm-client.c:2337 #38 async_inited_obj_nm (object=0x7fcac2073080 [NMRemoteConnection], result=0x7fcac2089ed0, user_data=0x7fcac2046820) at libnm/nm-client.c:2357 #39 g_simple_async_result_complete (simple=0x7fcac2089ed0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801 #40 init_async_parent_inited (error=0x0, init_data=0x7fcaa408a0f0) at libnm/nm-remote-connection.c:677 #41 init_async_parent_inited (source=<optimized out>, result=<optimized out>, user_data=0x7fcaa408a0f0) at libnm/nm-remote-connection.c:689 #42 g_simple_async_result_complete (simple=0x7fcac2089c30 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801 #43 complete_in_idle_cb (data=<optimized out>) at gsimpleasyncresult.c:813 #44 g_main_context_dispatch (context=0x7fcac204eea0) at gmain.c:3152 #45 g_main_context_dispatch (context=context@entry=0x7fcac204eea0) at gmain.c:3767 #46 g_main_context_iterate (context=0x7fcac204eea0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838 #47 g_main_loop_run (loop=0x7fcac2045ab0) at gmain.c:4032 #48 main (argc=<optimized out>, argv=<optimized out>) at clients/cli/nmcli.c:642 https://bugzilla.redhat.com/show_bug.cgi?id=1471245
2017-09-04 17:03:49 +02:00
g_signal_handlers_disconnect_by_data (priv->object_manager, self);
libnm: clear NMClientPrivate.object_manager in name_owner_changed() Don't leave dangling pointers.
2017-06-20 14:13:16 +02:00
g_clear_object (&priv->object_manager);
libnm: fix leaking cancellable in NMClient's name_owner_changed()
2017-06-20 14:22:19 +02:00
nm_clear_g_cancellable (&priv->new_object_manager_cancellable);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
priv->new_object_manager_cancellable = g_cancellable_new ();
prepare_object_manager (self, priv->new_object_manager_cancellable,
libnm: fix getting self pointer in NMClient's new_object_manager()
2017-06-20 14:20:38 +02:00
new_object_manager, self);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
} else {
g_signal_handlers_disconnect_by_func (object_manager, object_added, self);
unhook_om (self);
}
}
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void
libnm: split "NMManager" out of NMClient Clone NMClient as NMManager, and make NMClient just be a wrapper around that new class.
2014-09-24 13:14:48 -04:00
get_property (GObject *object, guint prop_id,
GValue *value, GParamSpec *pspec)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
NMClient *self = NM_CLIENT (object);
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (object);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
switch (prop_id) {
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
case PROP_DBUS_CONNECTION:
g_value_set_object (value, priv->dbus_connection);
break;
libnm: add NM_CLIENT_DBUS_NAME_OWNER property It's not yet implemented. But obviously it's interesting to get the name owner to which the NMClient is currently connected. Note only that: the name-owner property really says whether NM is currently running or not.
2019-10-15 16:08:36 +02:00
case PROP_DBUS_NAME_OWNER:
g_value_set_string (value, nm_client_get_dbus_name_owner (self));
break;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
case PROP_NM_RUNNING:
g_value_set_boolean (value, nm_client_get_nm_running (self));
break;
/* Manager properties. */
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_VERSION:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_string (value, nm_client_get_version (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_STATE:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_enum (value, nm_client_get_state (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_STARTUP:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_boolean (value, nm_client_get_startup (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_NETWORKING_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_boolean (value, nm_client_networking_get_enabled (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_WIRELESS_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_boolean (value, nm_client_wireless_get_enabled (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_WIRELESS_HARDWARE_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->manager)
libnm/client: proxy *_enabled and metered properties to the right object They're provided by the Manager, not by the RemoteSettings.
2017-11-01 21:29:39 +01:00
g_object_get_property (G_OBJECT (priv->manager), pspec->name, value);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else
g_value_set_boolean (value, FALSE);
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_WWAN_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_boolean (value, nm_client_wwan_get_enabled (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_WWAN_HARDWARE_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->manager)
libnm/client: proxy *_enabled and metered properties to the right object They're provided by the Manager, not by the RemoteSettings.
2017-11-01 21:29:39 +01:00
g_object_get_property (G_OBJECT (priv->manager), pspec->name, value);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else
g_value_set_boolean (value, FALSE);
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_WIMAX_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_boolean (value, nm_client_wimax_get_enabled (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_WIMAX_HARDWARE_ENABLED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->manager)
libnm/client: proxy *_enabled and metered properties to the right object They're provided by the Manager, not by the RemoteSettings.
2017-11-01 21:29:39 +01:00
g_object_get_property (G_OBJECT (priv->manager), pspec->name, value);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else
g_value_set_boolean (value, FALSE);
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_ACTIVE_CONNECTIONS:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_take_boxed (value, _nm_utils_copy_object_array (nm_client_get_active_connections (self)));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_CONNECTIVITY:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_enum (value, nm_client_get_connectivity (self));
break;
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
case PROP_CONNECTIVITY_CHECK_AVAILABLE:
g_value_set_boolean (value, nm_client_connectivity_check_get_available (self));
break;
case PROP_CONNECTIVITY_CHECK_ENABLED:
g_value_set_boolean (value, nm_client_connectivity_check_get_enabled (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_PRIMARY_CONNECTION:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_object (value, nm_client_get_primary_connection (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_ACTIVATING_CONNECTION:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_set_object (value, nm_client_get_activating_connection (self));
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_DEVICES:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_take_boxed (value, _nm_utils_copy_object_array (nm_client_get_devices (self)));
break;
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
case PROP_METERED:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->manager)
libnm/client: proxy *_enabled and metered properties to the right object They're provided by the Manager, not by the RemoteSettings.
2017-11-01 21:29:39 +01:00
g_object_get_property (G_OBJECT (priv->manager), pspec->name, value);
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
else
g_value_set_uint (value, NM_METERED_UNKNOWN);
break;
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
case PROP_ALL_DEVICES:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
g_value_take_boxed (value, _nm_utils_copy_object_array (nm_client_get_all_devices (self)));
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
break;
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
case PROP_CHECKPOINTS:
if (priv->manager)
g_object_get_property (G_OBJECT (priv->manager), pspec->name, value);
else
g_value_take_boxed (value, g_ptr_array_new ());
break;
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
/* Settings properties. */
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
case PROP_CONNECTIONS:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->settings)
g_object_get_property (G_OBJECT (priv->settings), pspec->name, value);
else
g_value_take_boxed (value, _nm_utils_copy_object_array (&empty));
break;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
case PROP_HOSTNAME:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->settings)
g_object_get_property (G_OBJECT (priv->settings), pspec->name, value);
else
g_value_set_string (value, NULL);
break;
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
case PROP_CAN_MODIFY:
libnm: use the o.fd.DBus.ObjectManager API for object management This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-18 16:35:07 +02:00
if (priv->settings)
g_object_get_property (G_OBJECT (priv->settings), pspec->name, value);
else
g_value_set_boolean (value, FALSE);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
break;
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
/* DNS properties */
case PROP_DNS_MODE:
case PROP_DNS_RC_MANAGER:
g_return_if_fail (pspec->name && strlen (pspec->name) > NM_STRLEN ("dns-"));
if (priv->dns_manager)
g_object_get_property (G_OBJECT (priv->dns_manager),
&pspec->name[NM_STRLEN ("dns-")], value);
else
g_value_set_string (value, NULL);
break;
case PROP_DNS_CONFIGURATION:
if (priv->dns_manager) {
g_object_get_property (G_OBJECT (priv->dns_manager),
NM_DNS_MANAGER_CONFIGURATION,
value);
} else
g_value_take_boxed (value, NULL);
break;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
static void
set_property (GObject *object, guint prop_id,
const GValue *value, GParamSpec *pspec)
{
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (object);
switch (prop_id) {
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
case PROP_DBUS_CONNECTION:
/* construct-only */
priv->dbus_connection = g_value_dup_object (value);
break;
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
case PROP_NETWORKING_ENABLED:
case PROP_WIRELESS_ENABLED:
case PROP_WWAN_ENABLED:
case PROP_WIMAX_ENABLED:
case PROP_CONNECTIVITY_CHECK_ENABLED:
if (priv->manager)
g_object_set_property (G_OBJECT (priv->manager), pspec->name, value);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
/*****************************************************************************/
static gboolean
init_sync (GInitable *initable, GCancellable *cancellable, GError **error)
{
NMClient *client = NM_CLIENT (initable);
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (client);
GList *objects, *iter;
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
if (!priv->dbus_connection) {
priv->dbus_connection = g_bus_get_sync (_nm_dbus_bus_type (),
cancellable,
error);
if (!priv->dbus_connection)
return FALSE;
}
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
priv->object_manager = g_dbus_object_manager_client_new_sync (priv->dbus_connection,
G_DBUS_OBJECT_MANAGER_CLIENT_FLAGS_DO_NOT_AUTO_START,
"org.freedesktop.NetworkManager",
"/org/freedesktop",
proxy_type, NULL, NULL,
cancellable, error);
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
if (!priv->object_manager)
return FALSE;
if (_om_has_name_owner (priv->object_manager)) {
if (!objects_created (client, priv->object_manager, error))
return FALSE;
objects = g_dbus_object_manager_get_objects (priv->object_manager);
for (iter = objects; iter; iter = iter->next) {
NMObject *obj_nm;
obj_nm = g_object_get_qdata (iter->data, _nm_object_obj_nm_quark ());
if (!obj_nm)
continue;
if (!g_initable_init (G_INITABLE (obj_nm), cancellable, NULL)) {
/* This is a can-not-happen situation, the NMObject subclasses are not
* supposed to fail initialization. */
g_warn_if_reached ();
}
}
g_list_free_full (objects, g_object_unref);
}
g_signal_connect (priv->object_manager, "notify::name-owner",
G_CALLBACK (name_owner_changed), client);
return TRUE;
}
/*****************************************************************************/
static void
init_async (GAsyncInitable *initable, int io_priority,
GCancellable *cancellable, GAsyncReadyCallback callback,
gpointer user_data)
{
prepare_object_manager (NM_CLIENT (initable), cancellable, callback, user_data);
}
static gboolean
init_finish (GAsyncInitable *initable, GAsyncResult *result, GError **error)
{
GSimpleAsyncResult *simple = G_SIMPLE_ASYNC_RESULT (result);
if (g_simple_async_result_propagate_error (simple, error))
return FALSE;
else
return TRUE;
}
/*****************************************************************************/
static void
libnm: remember the caller's GMainContext when creating NMClient We will require this later. The NMClient shall be tied to the GMainContext at the moment when the instance gets created. This allows the user to have multiple, indendent NMClient instances (on different threads and GMainContext). Currently this is still unused, it will be later.
2019-10-12 14:17:16 +02:00
nm_client_init (NMClient *self)
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
{
}
/**
* nm_client_new:
* @cancellable: a #GCancellable, or %NULL
* @error: location for a #GError, or %NULL
*
* Creates a new #NMClient.
*
* Note that this will do blocking D-Bus calls to initialize the
* client. You can use nm_client_new_async() if you want to avoid
* that.
*
* Returns: a new #NMClient or NULL on an error
**/
NMClient *
nm_client_new (GCancellable *cancellable,
GError **error)
{
return g_initable_new (NM_TYPE_CLIENT, cancellable, error,
NULL);
}
/**
* nm_client_new_async:
* @cancellable: a #GCancellable, or %NULL
* @callback: callback to call when the client is created
* @user_data: data for @callback
*
* Creates a new #NMClient and begins asynchronously initializing it.
* @callback will be called when it is done; use
* nm_client_new_finish() to get the result. Note that on an error,
* the callback can be invoked with two first parameters as NULL.
**/
void
nm_client_new_async (GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
{
libnm: don't use GSimpleAsyncResult for nm_client_new_async() As we don't have any data or our own, we don't need a GSimpleAsyncResult/GTask. Just pass the caller's @callback to g_async_initable_new_async().
2019-10-14 13:16:49 +02:00
g_async_initable_new_async (NM_TYPE_CLIENT,
G_PRIORITY_DEFAULT,
cancellable,
callback,
user_data,
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
NULL);
}
/**
* nm_client_new_finish:
* @result: a #GAsyncResult
* @error: location for a #GError, or %NULL
*
* Gets the result of an nm_client_new_async() call.
*
* Returns: a new #NMClient, or %NULL on error
**/
NMClient *
nm_client_new_finish (GAsyncResult *result, GError **error)
{
libnm: don't use GSimpleAsyncResult for nm_client_new_async() As we don't have any data or our own, we don't need a GSimpleAsyncResult/GTask. Just pass the caller's @callback to g_async_initable_new_async().
2019-10-14 13:16:49 +02:00
gs_unref_object GObject *source_object = NULL;
GObject *object;
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
libnm: don't use GSimpleAsyncResult for nm_client_new_async() As we don't have any data or our own, we don't need a GSimpleAsyncResult/GTask. Just pass the caller's @callback to g_async_initable_new_async().
2019-10-14 13:16:49 +02:00
source_object = g_async_result_get_source_object (result);
g_return_val_if_fail (source_object, NULL);
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
libnm: don't use GSimpleAsyncResult for nm_client_new_async() As we don't have any data or our own, we don't need a GSimpleAsyncResult/GTask. Just pass the caller's @callback to g_async_initable_new_async().
2019-10-14 13:16:49 +02:00
object = g_async_initable_new_finish (G_ASYNC_INITABLE (source_object),
result,
error);
g_return_val_if_fail (!object || NM_IS_CLIENT (object), FALSE);
return NM_CLIENT (object);
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
}
libnm: remember the caller's GMainContext when creating NMClient We will require this later. The NMClient shall be tied to the GMainContext at the moment when the instance gets created. This allows the user to have multiple, indendent NMClient instances (on different threads and GMainContext). Currently this is still unused, it will be later.
2019-10-12 14:17:16 +02:00
static void
constructed (GObject *object)
{
NMClient *self = NM_CLIENT (object);
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (self);
priv->main_context = g_main_context_ref_thread_default ();
G_OBJECT_CLASS (nm_client_parent_class)->constructed (object);
}
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
static void
dispose (GObject *object)
{
NMClientPrivate *priv = NM_CLIENT_GET_PRIVATE (object);
nm_clear_g_cancellable (&priv->new_object_manager_cancellable);
if (priv->manager) {
g_signal_handlers_disconnect_by_data (priv->manager, object);
g_clear_object (&priv->manager);
}
if (priv->settings) {
g_signal_handlers_disconnect_by_data (priv->settings, object);
g_clear_object (&priv->settings);
}
if (priv->dns_manager) {
g_signal_handlers_disconnect_by_data (priv->dns_manager, object);
g_clear_object (&priv->dns_manager);
}
if (priv->object_manager) {
GList *objects, *iter;
/* Unhook the NM objects. */
objects = g_dbus_object_manager_get_objects (priv->object_manager);
for (iter = objects; iter; iter = iter->next)
g_object_set_qdata (G_OBJECT (iter->data), _nm_object_obj_nm_quark (), NULL);
g_list_free_full (objects, g_object_unref);
g_signal_handlers_disconnect_by_data (priv->object_manager, object);
g_clear_object (&priv->object_manager);
}
G_OBJECT_CLASS (nm_client_parent_class)->dispose (object);
libnm: remember the caller's GMainContext when creating NMClient We will require this later. The NMClient shall be tied to the GMainContext at the moment when the instance gets created. This allows the user to have multiple, indendent NMClient instances (on different threads and GMainContext). Currently this is still unused, it will be later.
2019-10-12 14:17:16 +02:00
nm_clear_pointer (&priv->udev, udev_unref);
nm_clear_pointer (&priv->main_context, g_main_context_unref);
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
g_clear_object (&priv->dbus_connection);
libnm/trivial: move code in "nm-client.c"
2019-10-11 11:58:09 +02:00
nm_clear_g_free (&priv->name_owner_cached);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void
nm_client_class_init (NMClientClass *client_class)
{
GObjectClass *object_class = G_OBJECT_CLASS (client_class);
object_class->get_property = get_property;
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
object_class->set_property = set_property;
libnm: remember the caller's GMainContext when creating NMClient We will require this later. The NMClient shall be tied to the GMainContext at the moment when the instance gets created. This allows the user to have multiple, indendent NMClient instances (on different threads and GMainContext). Currently this is still unused, it will be later.
2019-10-12 14:17:16 +02:00
object_class->constructed = constructed;
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
object_class->dispose = dispose;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
/**
* NMClient:dbus-connection:
*
* The #GDBusConnection to use.
*
* If this is not set during object construction, the D-Bus connection will
* automatically be chosen during async/sync initalization via g_bus_get().
*
* Since: 1.22
*/
obj_properties[PROP_DBUS_CONNECTION] =
g_param_spec_object (NM_CLIENT_DBUS_CONNECTION, "", "",
G_TYPE_DBUS_CONNECTION,
G_PARAM_READABLE |
G_PARAM_WRITABLE |
G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
libnm: add NM_CLIENT_DBUS_NAME_OWNER property It's not yet implemented. But obviously it's interesting to get the name owner to which the NMClient is currently connected. Note only that: the name-owner property really says whether NM is currently running or not.
2019-10-15 16:08:36 +02:00
/**
* NMClient:dbus-name-owner:
*
* The name owner of the NetworkManager D-Bus service.
*
* Since: 1.22
**/
obj_properties[PROP_DBUS_NAME_OWNER] =
g_param_spec_string (NM_CLIENT_DBUS_NAME_OWNER, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add NM_CLIENT_DBUS_CONNECTION property The used GDBusConnection should be configurable when creating the NMClient instance. Automatically choosing one of the g_bus_get() singletons is fine by default, but it's an unnecessary limitation.
2019-10-12 14:59:23 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:version:
*
* The NetworkManager version.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_VERSION] =
g_param_spec_string (NM_CLIENT_VERSION, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:state:
*
* The current daemon state.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_STATE] =
g_param_spec_enum (NM_CLIENT_STATE, "", "",
NM_TYPE_STATE,
NM_STATE_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:startup:
*
* Whether the daemon is still starting up.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_STARTUP] =
g_param_spec_boolean (NM_CLIENT_STARTUP, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
libnm: synchronize NMClient and NMRemoteSettings "is NM running" properties Rename NMClient:manager-running and NMRemoteSettings:service-running to both be :nm-running.
2014-08-05 10:05:26 -04:00
* NMClient:nm-running:
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
* Whether the daemon is running.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_NM_RUNNING] =
g_param_spec_boolean (NM_CLIENT_NM_RUNNING, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:networking-enabled:
*
* Whether networking is enabled.
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* The property setter is a synchronous D-Bus call. This is deprecated since 1.22.
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_NETWORKING_ENABLED] =
g_param_spec_boolean (NM_CLIENT_NETWORKING_ENABLED, "", "",
libnm: change default value for NMClient:{networking,wireless-hardware}-enabled properties
2019-10-21 18:34:09 +02:00
FALSE,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:wireless-enabled:
*
* Whether wireless is enabled.
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* The property setter is a synchronous D-Bus call. This is deprecated since 1.22.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_WIRELESS_ENABLED] =
g_param_spec_boolean (NM_CLIENT_WIRELESS_ENABLED, "", "",
FALSE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:wireless-hardware-enabled:
*
* Whether the wireless hardware is enabled.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_WIRELESS_HARDWARE_ENABLED] =
g_param_spec_boolean (NM_CLIENT_WIRELESS_HARDWARE_ENABLED, "", "",
libnm: change default value for NMClient:{networking,wireless-hardware}-enabled properties
2019-10-21 18:34:09 +02:00
FALSE,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:wwan-enabled:
*
* Whether WWAN functionality is enabled.
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* The property setter is a synchronous D-Bus call. This is deprecated since 1.22.
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_WWAN_ENABLED] =
g_param_spec_boolean (NM_CLIENT_WWAN_ENABLED, "", "",
FALSE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:wwan-hardware-enabled:
*
* Whether the WWAN hardware is enabled.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_WWAN_HARDWARE_ENABLED] =
g_param_spec_boolean (NM_CLIENT_WWAN_HARDWARE_ENABLED, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:wimax-enabled:
*
* Whether WiMAX functionality is enabled.
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* The property setter is a synchronous D-Bus call. This is deprecated since 1.22.
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_WIMAX_ENABLED] =
g_param_spec_boolean (NM_CLIENT_WIMAX_ENABLED, "", "",
FALSE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:wimax-hardware-enabled:
*
* Whether the WiMAX hardware is enabled.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_WIMAX_HARDWARE_ENABLED] =
g_param_spec_boolean (NM_CLIENT_WIMAX_HARDWARE_ENABLED, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
gobject-introspection: made several fixes to the annotations https://bugzilla.gnome.org/show_bug.cgi?id=794658
2018-03-24 15:18:21 +00:00
* NMClient:active-connections: (type GPtrArray(NMActiveConnection))
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
* The active connections.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_ACTIVE_CONNECTIONS] =
g_param_spec_boxed (NM_CLIENT_ACTIVE_CONNECTIONS, "", "",
G_TYPE_PTR_ARRAY,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:connectivity:
*
* The network connectivity state.
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_CONNECTIVITY] =
g_param_spec_enum (NM_CLIENT_CONNECTIVITY, "", "",
NM_TYPE_CONNECTIVITY_STATE,
NM_CONNECTIVITY_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
/**
* NMClient::connectivity-check-available
*
* Whether a connectivity checking service has been configured.
libnm: add gtk-doc Since markers for new API and missing enum documentation
2017-08-17 23:08:44 +02:00
*
* Since: 1.10
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_CONNECTIVITY_CHECK_AVAILABLE] =
g_param_spec_boolean (NM_CLIENT_CONNECTIVITY_CHECK_AVAILABLE, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
/**
* NMClient::connectivity-check-enabled
*
* Whether a connectivity checking service has been enabled.
libnm: add gtk-doc Since markers for new API and missing enum documentation
2017-08-17 23:08:44 +02:00
*
* Since: 1.10
libnm: deprecate synchronous/blocking API in libnm Note that D-Bus is fundamentally asynchronous. Doing blocking calls on top of D-Bus is odd, especially for libnm's NMClient. That is because NMClient essentially is a client-side cache of the objects from the D-Bus interface. This cache should be filled exclusively by (asynchronous) D-Bus events (PropertiesChanged). So, making a blocking D-Bus call means to wait for a response and return it, while queuing all messages that are received in the meantime. Basically there are three ways how a synchronous API on NMClient could behave: 1) the call just calls g_dbus_connection_call_sync(). This means that libnm sends a D-Bus request via GDBusConnection, and blockingly waits for the response. All D-Bus messages that get received in the meantime are queued in the GMainContext that belongs to NMClient. That means, none of these D-Bus events are processed until we iterate the GMainContext after the call returns. The effect is, that NMClient (and all cached objects in there) are unaffected by the D-Bus request. Most of the synchronous API calls in libnm are of this kind. The problem is that the strict ordering of D-Bus events gets violated. For some API this is not an immediate problem. Take for example nm_device_wifi_request_scan(). The call merely blockingly tells NetworkManager to start scanning, but since NetworkManager's D-Bus API does not directly expose any state that tells whether we are currently scanning, this out of order processing of the D-Bus request is a small issue. The problem is more obvious for nm_client_networking_set_enabled(). After calling it, NM_CLIENT_NETWORKING_ENABLED is still unaffected and unchanged, because the PropertiesChanged signal from D-Bus is not yet processed. This means, while you make such a blocking call, NMClient's state does not change. But usually you perform the synchronous call to change some state. In this form, the blocking call is not useful, because NMClient only changes the state after iterating the GMainContext, and not after the blocking call returns. 2) like 1), but after making the blocking g_dbus_connection_call_sync(), update the NMClient cache artificially. This is what nm_manager_check_connectivity() does, to "fix" bgo#784629. This also has the problem of out-of-order events, but it kinda solves the problem of not changing the state during the blocking call. But it does so by hacking the state of the cache. I think this is really wrong because the state should only be updated from the ordered stream of D-Bus messages (PropertiesChanged signal and similar). When libnm decides to modify the state, there may be already D-Bus messages queued that affect this very state. 3) instead of calling g_dbus_connection_call_sync(), use the asynchronous g_dbus_connection_call(). If we would use a sepaate GMainContext for all D-Bus related calls, we could ensure that while we block for the response, we iterate that internal main context. This might be nice, because all events are processed in order and after the blocking call returns, the NMClient state is up to date. The are problems however: current blocking API does not do this, so it's a significant change in behavior. Also, it might be unexpected to the user that during the blocking call the entire content of NMClient's cache might change and all pointers to the cache might be invalidated. Also, of course NMClient would invoke signals for all the changes that happen. Another problem is that this would be more effort to implement and it involves a small performance overhead for all D-Bus related calls (because we have to serialize all events in an internal GMainContext first and then invoke them on the caller's context). Also, if the users wants this behavior, they could implement it themself by running libnm in their own GMainContext. Note that libnm might have bugs to make that really working, but that should be fixed instead of adding such synchrnous API behavior. Read also [1], for why blocking calls are wrong. [1] https://smcv.pseudorandom.co.uk/2008/11/nonblocking/ So, all possible behaviors for synchronous API have severe behavioural issues. Mark all this API as deprecated. Also, this serves the purpose of identifying blocking D-Bus calls in libnm. Note that "deprecated" here does not really mean that the API is going to be removed. We don't break API. The user may: - continue to use this API. It's deprecated, awkward and discouraged, but if it works, by all means use it. - use asynchronous API. That's the only sensible way to use D-Bus. If libnm lacks a certain asynchronous counterpart, it should be added. - use GDBusConnection directly. There really isn't anything wrong with D-Bus or GDBusConnection. This deprecated API is just a wrapper around g_dbus_connection_call_sync(). You may call it directly without feeling dirty. --- The only other remainging API is the synchronous GInitable call for NMClient. That is an entirely separate beast and not particularly wrong (from an API point of view). Note that synchronous API in NMSecretAgentOld, NMVpnPluginOld and NMVpnServicePlugin as not deprecated here. These types are not part of the D-Bus cache and while they have similar issues, it's less severe because they have less state.
2019-09-04 13:58:43 +02:00
*
* The property setter is a synchronous D-Bus call. This is deprecated since 1.22.
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_CONNECTIVITY_CHECK_ENABLED] =
g_param_spec_boolean (NM_CLIENT_CONNECTIVITY_CHECK_ENABLED, "", "",
FALSE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
client: expose connectivity-check-{available,enabled} properties https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:21:28 +08:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:primary-connection:
*
* The #NMActiveConnection of the device with the default route;
* see nm_client_get_primary_connection() for more details.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_PRIMARY_CONNECTION] =
g_param_spec_object (NM_CLIENT_PRIMARY_CONNECTION, "", "",
NM_TYPE_ACTIVE_CONNECTION,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient:activating-connection:
*
* The #NMActiveConnection of the activating connection that is
* likely to become the new #NMClient:primary-connection.
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_ACTIVATING_CONNECTION] =
g_param_spec_object (NM_CLIENT_ACTIVATING_CONNECTION, "", "",
NM_TYPE_ACTIVE_CONNECTION,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
gobject-introspection: made several fixes to the annotations https://bugzilla.gnome.org/show_bug.cgi?id=794658
2018-03-24 15:18:21 +00:00
* NMClient:devices: (type GPtrArray(NMDevice))
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
* List of real network devices. Does not include placeholder devices.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_DEVICES] =
g_param_spec_boxed (NM_CLIENT_DEVICES, "", "",
G_TYPE_PTR_ARRAY,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
/**
gobject-introspection: made several fixes to the annotations https://bugzilla.gnome.org/show_bug.cgi?id=794658
2018-03-24 15:18:21 +00:00
* NMClient:all-devices: (type GPtrArray(NMDevice))
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
*
* List of both real devices and device placeholders.
* Since: 1.2
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_ALL_DEVICES] =
g_param_spec_boxed (NM_CLIENT_ALL_DEVICES, "", "",
G_TYPE_PTR_ARRAY,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
gobject-introspection: made several fixes to the annotations https://bugzilla.gnome.org/show_bug.cgi?id=794658
2018-03-24 15:18:21 +00:00
* NMClient:connections: (type GPtrArray(NMRemoteConnection))
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
*
* The list of configured connections that are available to the user. (Note
* that this differs from the underlying D-Bus property, which may also
* contain the object paths of connections that the user does not have
* permission to read the details of.)
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_CONNECTIONS] =
g_param_spec_boxed (NM_CLIENT_CONNECTIONS, "", "",
G_TYPE_PTR_ARRAY,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
* NMClient:hostname:
*
* The machine hostname stored in persistent configuration. This can be
* modified by calling nm_client_save_hostname().
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_HOSTNAME] =
g_param_spec_string (NM_CLIENT_HOSTNAME, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
* NMClient:can-modify:
*
* If %TRUE, adding and modifying connections is supported.
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_CAN_MODIFY] =
g_param_spec_boolean (NM_CLIENT_CAN_MODIFY, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
/**
* NMClient:metered:
*
* Whether the connectivity is metered.
*
* Since: 1.2
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_METERED] =
g_param_spec_uint (NM_CLIENT_METERED, "", "",
0, G_MAXUINT32, NM_METERED_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
nm-manager: add 'metered' property This introduces a global metered property which makes easier for clients to obtain the metered status of the current primary connection.
2015-06-03 09:15:24 +02:00
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
/**
* NMClient:dns-mode:
*
* The current DNS processing mode.
*
* Since: 1.6
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_DNS_MODE] =
g_param_spec_string (NM_CLIENT_DNS_MODE, "", "",
libnm: change default value for NMClient:dns-{mode,rc-manager} properties
2019-10-21 18:34:09 +02:00
NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
/**
* NMClient:dns-rc-manager:
*
* The current resolv.conf management mode.
*
* Since: 1.6
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_DNS_RC_MANAGER] =
g_param_spec_string (NM_CLIENT_DNS_RC_MANAGER, "", "",
libnm: change default value for NMClient:dns-{mode,rc-manager} properties
2019-10-21 18:34:09 +02:00
NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
/**
libnm: fix dns-configuration property type Fixes: a8d600525643 ('libnm: implement support for DNS manager properties') https://bugzilla.redhat.com/show_bug.cgi?id=1689055 (cherry picked from commit d867837d05a808ff90756a41a96f778846522465)
2019-03-15 09:41:51 +01:00
* NMClient:dns-configuration: (type GPtrArray(NMDnsEntry))
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
*
libnm: fix dns-configuration property type Fixes: a8d600525643 ('libnm: implement support for DNS manager properties') https://bugzilla.redhat.com/show_bug.cgi?id=1689055 (cherry picked from commit d867837d05a808ff90756a41a96f778846522465)
2019-03-15 09:41:51 +01:00
* The current DNS configuration, represented as an array
* of #NMDnsEntry objects.
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
*
* Since: 1.6
**/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_DNS_CONFIGURATION] =
g_param_spec_boxed (NM_CLIENT_DNS_CONFIGURATION, "", "",
G_TYPE_PTR_ARRAY,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: implement support for DNS manager properties
2016-10-25 11:11:12 +02:00
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
/**
gobject-introspection: made several fixes to the annotations https://bugzilla.gnome.org/show_bug.cgi?id=794658
2018-03-24 15:18:21 +00:00
* NMClient:checkpoints: (type GPtrArray(NMCheckpoint))
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
*
* The list of active checkpoints.
*
* Since: 1.12
*/
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
obj_properties[PROP_CHECKPOINTS] =
g_param_spec_boxed (NM_MANAGER_CHECKPOINTS, "", "",
G_TYPE_PTR_ARRAY,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
libnm: add checkpoint support
2017-10-21 16:05:19 +02:00
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient::device-added:
* @client: the client that received the signal
* @device: (type NMDevice): the new device
*
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
* Notifies that a #NMDevice is added. This signal is not emitted for
* placeholder devices.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
signals[DEVICE_ADDED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_DEVICE_ADDED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
0, NULL, NULL, NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_TYPE_NONE, 1,
G_TYPE_OBJECT);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient::device-removed:
* @client: the client that received the signal
* @device: (type NMDevice): the removed device
*
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
* Notifies that a #NMDevice is removed. This signal is not emitted for
* placeholder devices.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
signals[DEVICE_REMOVED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_DEVICE_REMOVED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
0, NULL, NULL, NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_TYPE_NONE, 1,
G_TYPE_OBJECT);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
/**
* NMClient::any-device-added:
* @client: the client that received the signal
* @device: (type NMDevice): the new device
*
* Notifies that a #NMDevice is added. This signal is emitted for both
* regular devices and placeholder devices.
**/
signals[ANY_DEVICE_ADDED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_ANY_DEVICE_ADDED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
0, NULL, NULL, NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_TYPE_NONE, 1,
G_TYPE_OBJECT);
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
/**
* NMClient::any-device-removed:
* @client: the client that received the signal
* @device: (type NMDevice): the removed device
*
* Notifies that a #NMDevice is removed. This signal is emitted for both
* regular devices and placeholder devices.
**/
signals[ANY_DEVICE_REMOVED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_ANY_DEVICE_REMOVED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
0, NULL, NULL, NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_TYPE_NONE, 1,
G_TYPE_OBJECT);
libnm/libnm-glib: add NMClient.get_all_devices() method and AllDevices property Mirror new NetworkManager API to return both real devices and device placeholders.
2014-10-10 14:28:49 -05:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMClient::permission-changed:
* @client: the client that received the signal
* @permission: a permission from #NMClientPermission
* @result: the permission's result, one of #NMClientPermissionResult
*
* Notifies that a permission has changed
**/
signals[PERMISSION_CHANGED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_PERMISSION_CHANGED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 2, G_TYPE_UINT, G_TYPE_UINT);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
* NMClient::connection-added:
* @client: the settings object that received the signal
* @connection: the new connection
*
* Notifies that a #NMConnection has been added.
**/
signals[CONNECTION_ADDED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_CONNECTION_ADDED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
0, NULL, NULL, NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_TYPE_NONE, 1,
NM_TYPE_REMOTE_CONNECTION);
libnm: merge NMRemoteSettings into NMClient Make NMRemoteSettings internal and have NMClient wrap all of its APIs, just like it does with NMManager.
2014-09-29 10:58:16 -04:00
/**
* NMClient::connection-removed:
* @client: the settings object that received the signal
* @connection: the removed connection
*
* Notifies that a #NMConnection has been removed.
**/
signals[CONNECTION_REMOVED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_CONNECTION_REMOVED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
libnm: hide NMClient struct from public headers and use direct private field Having the NMClient/NMClientClass structs in the public header allows the user to subclass these types. Subclassing this type was never intended, nor is it supported, nor does it seem useful. Subclassing only makes sense if the type has suitable hooks to extend the type in a meaningful way. NMClient hasn't, and everybody trying to derive from this class would better delegate the actions. Also, having these structs in the public header prevents us from embedding the private data in the object structure itself. It has thus an runtime overhead and is less convenient for debugging (it's hard to find the private data pointer in gdb). Most importantly, there is no easy way to find the offset of the private data fields, short of calling NM_CLIENT_GET_PRIVATE() -- which currently is a macro. Later we want to generically lookup the offset of the private data, we would need NM_CLIENT_GET_PRIVATE() as a function. Instead, by having an internally, statically known offset, we can use that offset instead. Also drop all signal hooks. They are also not useful. This is an ABI and API change, but of something that we never wanted to be part of the ABI/API, and which hopefull nobody is using.
2019-10-18 07:44:31 +02:00
0, NULL, NULL, NULL,
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
G_TYPE_NONE, 1,
NM_TYPE_REMOTE_CONNECTION);
libnm/client: emit signals when active connection disappears It allows us to reliably track failures to activate a connection.
2016-07-07 11:35:19 +02:00
/**
* NMClient::active-connection-added:
* @client: the settings object that received the signal
* @active_connection: the new active connection
*
* Notifies that a #NMActiveConnection has been added.
**/
signals[ACTIVE_CONNECTION_ADDED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_ACTIVE_CONNECTION_ADDED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 1,
NM_TYPE_ACTIVE_CONNECTION);
libnm/client: emit signals when active connection disappears It allows us to reliably track failures to activate a connection.
2016-07-07 11:35:19 +02:00
/**
* NMClient::active-connection-removed:
* @client: the settings object that received the signal
* @active_connection: the removed active connection
*
* Notifies that a #NMActiveConnection has been removed.
**/
signals[ACTIVE_CONNECTION_REMOVED] =
libnm: use obj_properties array in libnm and cleanup This is not merely cosmetic. I will need the obj_properties array to lookup GParamSpec by their PROP_* enum value. The alternative would be lookup by name, which is more expensive.
2019-10-10 17:57:30 +02:00
g_signal_new (NM_CLIENT_ACTIVE_CONNECTION_REMOVED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 1,
NM_TYPE_ACTIVE_CONNECTION);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
static void
nm_client_initable_iface_init (GInitableIface *iface)
{
iface->init = init_sync;
}
static void
nm_client_async_initable_iface_init (GAsyncInitableIface *iface)
{
iface->init_async = init_async;
iface->init_finish = init_finish;
}
libnm: move backported symbols from libnm-core to libnm Backported symbols only make sense for libnm itself, not for libnm-core which is statically linked with NetworkManager and nm-ifcace-helper. Declaring the symbols in libnm-core, means that NetworkManager binary also contains them, although there are not used. Move them to libnm.
2016-10-12 11:26:26 +02:00
/*****************************************************************************
* Backported symbols. Usually, new API is only added in new major versions
* of NetworkManager (that is, on "master" branch). Sometimes however, we might
* have to backport some API to an older stable branch. In that case, we backport
* the symbols with a different version corresponding to the minor API.
*
* To allow upgrading from such a extended minor-release, "master" contains these
* backported symbols too.
*
* For example, 1.2.0 added nm_setting_connection_autoconnect_slaves_get_type.
* This was backported for 1.0.4 as nm_setting_connection_autoconnect_slaves_get_type@libnm_1_0_4
* To allow an application that was linked against 1.0.4 to seamlessly upgrade to
* a newer major version, the same symbols is also exposed on "master". Note, that
* a user can only seamlessly upgrade to a newer major version, that is released
* *after* 1.0.4 is out. In this example, 1.2.0 was released after 1.4.0, and thus
* a 1.0.4 user can upgrade to 1.2.0 ABI.
*****************************************************************************/
NM_BACKPORT_SYMBOL (libnm_1_0_4, NMSettingConnectionAutoconnectSlaves, nm_setting_connection_get_autoconnect_slaves, (NMSettingConnection *setting), (setting));
NM_BACKPORT_SYMBOL (libnm_1_0_4, GType, nm_setting_connection_autoconnect_slaves_get_type, (void), ());
NM_BACKPORT_SYMBOL (libnm_1_0_6, NMMetered, nm_setting_connection_get_metered, (NMSettingConnection *setting), (setting));
NM_BACKPORT_SYMBOL (libnm_1_0_6, GType, nm_metered_get_type, (void), ());
NM_BACKPORT_SYMBOL (libnm_1_0_6, NMSettingWiredWakeOnLan, nm_setting_wired_get_wake_on_lan,
(NMSettingWired *setting), (setting));
NM_BACKPORT_SYMBOL (libnm_1_0_6, const char *, nm_setting_wired_get_wake_on_lan_password,
(NMSettingWired *setting), (setting));
NM_BACKPORT_SYMBOL (libnm_1_0_6, GType, nm_setting_wired_wake_on_lan_get_type, (void), ());
NM_BACKPORT_SYMBOL (libnm_1_0_6, const guint *, nm_utils_wifi_2ghz_freqs, (void), ());
NM_BACKPORT_SYMBOL (libnm_1_0_6, const guint *, nm_utils_wifi_5ghz_freqs, (void), ());
NM_BACKPORT_SYMBOL (libnm_1_0_6, char *, nm_utils_enum_to_str,
(GType type, int value), (type, value));
NM_BACKPORT_SYMBOL (libnm_1_0_6, gboolean, nm_utils_enum_from_str,
(GType type, const char *str, int *out_value, char **err_token),
(type, str, out_value, err_token));
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
NM_BACKPORT_SYMBOL (libnm_1_2_4, int, nm_setting_ip_config_get_dns_priority, (NMSettingIPConfig *setting), (setting));
libnm: add mdns backported symbols from 1.10.14 Add to master branch mdns symbols that were backported to 1.10.14 to allow seamless upgrading from 1.10 to 1.16.
2018-10-19 19:12:53 +02:00
NM_BACKPORT_SYMBOL (libnm_1_10_14, NMSettingConnectionMdns, nm_setting_connection_get_mdns,
(NMSettingConnection *setting), (setting));
NM_BACKPORT_SYMBOL (libnm_1_10_14, GType, nm_setting_connection_mdns_get_type, (void), ());
Reference in a new issue Copy permalink