Skip to content
  • Thomas Haller's avatar
    bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data · 4154d961
    Thomas Haller authored
    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.
    4154d961