libnm: use the o.fd.DBus.ObjectManager API for object management

System Internals / NetworkManager - Lubomir Rintel [v3.sk] - 10 November 2016 09:48 UTC

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.

1f5b48a libnm: use the o.fd.DBus.ObjectManager API for object management
Makefile.am | 6 +-
docs/libnm/Makefile.am | 1 -
libnm/nm-access-point.c | 2 -
libnm/nm-active-connection.c | 22 +-
libnm/nm-client.c | 695 ++++++++++++++++++++++++++++++---
libnm/nm-dbus-helpers.c | 99 +----
libnm/nm-dbus-helpers.h | 21 +-
libnm/nm-device-adsl.c | 4 -
libnm/nm-device-bond.c | 5 -
libnm/nm-device-bridge.c | 5 -
libnm/nm-device-bt.c | 4 -
libnm/nm-device-ethernet.c | 4 -
libnm/nm-device-generic.c | 4 -
libnm/nm-device-infiniband.c | 4 -
libnm/nm-device-ip-tunnel.c | 4 -
libnm/nm-device-macvlan.c | 4 -
libnm/nm-device-modem.c | 4 -
libnm/nm-device-olpc-mesh.c | 4 -
libnm/nm-device-private.h | 26 --
libnm/nm-device-team.c | 5 -
libnm/nm-device-tun.c | 4 -
libnm/nm-device-vlan.c | 4 -
libnm/nm-device-vxlan.c | 4 -
libnm/nm-device-wifi.c | 8 -
libnm/nm-device-wimax.c | 6 -
libnm/nm-device.c | 193 +---------
libnm/nm-dhcp4-config.c | 3 -
libnm/nm-dhcp6-config.c | 3 -
libnm/nm-ip4-config.c | 3 -
libnm/nm-ip6-config.c | 3 -
libnm/nm-manager.c | 263 ++-----------
libnm/nm-manager.h | 2 -
libnm/nm-object-cache.c | 90 -----
libnm/nm-object-cache.h | 35 --
libnm/nm-object-private.h | 29 +-
libnm/nm-object.c | 865 ++++++++----------------------------------
libnm/nm-object.h | 2 +
libnm/nm-remote-connection.c | 98 ++---
libnm/nm-remote-settings.c | 72 ----
libnm/nm-vpn-connection.c | 4 -
libnm/nm-wimax-nsp.c | 2 -
41 files changed, 891 insertions(+), 1725 deletions(-)

Upstream: cgit.freedesktop.org

  • Share