bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data

System Internals / NetworkManager - Thomas Haller [redhat.com] - 23 September 2019 10:47 EDT

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.

4154d9618 bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
Makefile.am | 5 +-
libnm-core/nm-core-internal.h | 4 +
libnm-core/nm-utils.c | 8 +
po/POTFILES.in | 2 +-
src/devices/bluetooth/meson.build | 2 -
src/devices/bluetooth/nm-bluez-device.c | 1207 ------------
src/devices/bluetooth/nm-bluez-device.h | 70 -
src/devices/bluetooth/nm-bluez-manager.c | 2885 +++++++++++++++++++++++++++--
src/devices/bluetooth/nm-bluez-manager.h | 39 +
src/devices/bluetooth/nm-bluez5-dun.c | 910 ++++++---
src/devices/bluetooth/nm-bluez5-dun.h | 41 +-
src/devices/bluetooth/nm-bluez5-manager.c | 585 ------
src/devices/bluetooth/nm-bluez5-manager.h | 27 -
src/devices/bluetooth/nm-device-bt.c | 855 +++++----
src/devices/bluetooth/nm-device-bt.h | 34 +-
src/devices/bluetooth/tests/nm-bt-test.c | 202 +-
src/devices/nm-device-bridge.c | 98 +-
src/devices/nm-device-bridge.h | 3 +
src/devices/nm-device-factory.c | 22 +-
src/devices/nm-device-factory.h | 35 -
src/devices/nm-device.c | 40 +-
src/devices/nm-device.h | 33 +-
src/devices/wwan/nm-modem.c | 7 +-
src/devices/wwan/nm-wwan-factory.c | 11 +-
src/nm-manager.c | 32 +-
src/nm-manager.h | 2 +
26 files changed, 4321 insertions(+), 2838 deletions(-)

Upstream: cgit.freedesktop.org


  • Share