From 5131cc42455f0de7bb7538ecd2b9d811fb246d2c Mon Sep 17 00:00:00 2001 From: Thomas Haller Date: Fri, 23 Aug 2019 16:45:39 +0200 Subject: core: add and use NM_MANAGER_GET macro For our singleton getters we usually have such a macro. See NM_PLATFORM_GET and NM_SETTINGS_GET. Add such a macro for NMManager and use it. --- src/nm-manager.h | 1 + 1 file changed, 1 insertion(+) (limited to 'src/nm-manager.h') diff --git a/src/nm-manager.h b/src/nm-manager.h index f7726873bf..bedd004e81 100644 --- a/src/nm-manager.h +++ b/src/nm-manager.h @@ -64,6 +64,7 @@ GType nm_manager_get_type (void); NMManager * nm_manager_setup (void); NMManager * nm_manager_get (void); +#define NM_MANAGER_GET (nm_manager_get ()) gboolean nm_manager_start (NMManager *manager, GError **error); -- cgit v1.2.1 From 4154d9618c904c2286b332b56f3515806cb1bb3b Mon Sep 17 00:00:00 2001 From: Thomas Haller Date: Sun, 11 Aug 2019 10:43:53 +0200 Subject: bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data This is a complete refactoring of the bluetooth code. Now that BlueZ 4 support was dropped, the separation of NMBluezManager and NMBluez5Manager makes no sense. They should be merged. At that point, notice that BlueZ 5's D-Bus API is fully centered around D-Bus's ObjectManager interface. Using that interface, we basically only call GetManagedObjects() once and register to InterfacesAdded, InterfacesRemoved and PropertiesChanged signals. There is no need to fetch individual properties ever. Note how NMBluezDevice used to query the D-Bus properties itself by creating a GDBusProxy. This is redundant, because when using the ObjectManager interfaces, we have all information already. Instead, let NMBluezManager basically become the client-side cache of all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned about caching the D-Bus interface's state, tracking suitable profiles (pan_connection), and moderate between bluez and NMDeviceBt. These tasks don't get simpler by moving them to a seprate file. Let them also be handled by NMBluezManager. I mean, just look how it was previously: NMBluez5Manager registers to ObjectManager interface and sees a device appearing. It creates a NMBluezDevice object and registers to its "initialized" and "notify:usable" signal. In the meantime, NMBluezDevice fetches the relevant information from D-Bus (although it was already present in the data provided by the ObjectManager) and eventually emits these usable and initialized signals. Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and NMBluezDevice are strongly cooperating to the point that it is simpler to merge them. This is not mere refactoring. This patch aims to make everything asynchronously and always cancellable. Also, it aims to fix races and inconsistencies of the state. - Registering to a NAP server now waits for the response and delays activation of the NMDeviceBridge accordingly. - For NAP connections we now watch the bnep0 interface in platform, and tear down the device when it goes away. Bluez doesn't send us a notification on D-Bus in that case. - Rework establishing a DUN connection. It no longer uses blocking connect() and does not block until rfcomm device appears. It's all async now. It also watches the rfcomm file descriptor for POLLERR/POLLHUP to notice disconnect. - drop nm_device_factory_emit_component_added() and instead let NMDeviceBt directly register to the WWan factory's "added" signal. --- src/nm-manager.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'src/nm-manager.h') diff --git a/src/nm-manager.h b/src/nm-manager.h index bedd004e81..187ce72863 100644 --- a/src/nm-manager.h +++ b/src/nm-manager.h @@ -191,4 +191,6 @@ void nm_manager_dbus_set_property_handle (NMDBusObject *obj, NMMetered nm_manager_get_metered (NMManager *self); +void nm_manager_notify_device_availibility_maybe_changed (NMManager *self); + #endif /* __NETWORKMANAGER_MANAGER_H__ */ -- cgit v1.2.1