[linux] dbus sharing design

[turon]

Problem

Extend PlatformMgr to allow service registration to select loop.
Each service creates its own thread to drive DBUS: Thread, BLE, WiFi.
Need a consistent way to register such services to drive DBUS in a common way.

Proposed Solution

Map out pros and cons of each approach below.
Down-select solution.
Implement solution with unit tests.

1. Allow service to register with PlatformMgr main select loop.
   delegate struct { .prepareSelect, .update }

2. Or dedicated I/O thread for DBUS

3. Or separate threads, but common way to drive DBUS

[turon]

#1147 includes a proposed design for dbus sharing in the Thread linux implementation.
Next step is to separate out generic dbus portions into a separate PR [@gjc13].

[yufengwangca]

I used to hit some issues with calling dbus methods from multiple threads during dbus_mojo_adaptor development.

I think the best way to handle this issue is to have a single thread running dbus dispatcher, BT, WiFi, Thread all register their own object path and own their own dbus interface, but all of them share the unique dbus connection established by the D-Bus IO thread

[turon]

From weekly call:

@turon How to test generic dbus handler w/o tie to ble, wifi, or other usage?
@yufengwangca : interface to some generic dbus
@yunhanw-google : dbus send or dbus core
@kghost : choice of using gio or raw dbus?
@yufengwangca : embedded linux library preferred.
@kghost : openwrt has it, but larger library -- may not exist on all linux
@yunhanw-google : larger linux implementation leverages xml codegen which would be good to leverage
@turon : availability on RasPi should be gate for whether to consider available
@kghost : gio is available on RasPi
@yufengwangca : should use raw API -- libdbus. Also have simple wrapper around libdbus.
@yunhanw-google : suggest porting nldbus as helper lib
@yufengwangca : libdbus is very primitive
@turon : evaluate ell library? https://git.kernel.org/pub/scm/libs/ell/ell.git/tree (https://01.org/ell)
@yufengwangca : nldbus preferred. will start design doc for review over coming week.

[turon]

@yufengwangca : proceeding with gio/glib approach. Proceeding to implementation stage. 2-3 days expected.
@turon: consider having some general APIs for adding services -- bothRegisterSelectService and RegisterGioService
@yunhanw-google : can work with you on BLE integration part
@yufengwangca : WiFi / wpasupplicant part also using gio.
Concerned about potential conflict with ThreadMgr using raw dbus API in parallel.
@bukepo : Doesn't gio use the raw dbus API? Is WiFi using gio right now?
@kghost : No, gio has their own from scratch impl. Yes, both WiFi and BLE using gio right now.
@yufengwangca : WiFi using pre-defined gio dbus API from wpasupplicant.
@bukepo : Ok, we could convert ThreadMgr to gio when we have time.
@yufengwangca : Think that will be required to prevent conflicts
@bukepo : Believe gio can handle raw file descriptors
@yufengwangca : Didn't try that, but anticipate there would be subtle problems with that, unless it has its own thread
@turon : Current Thread impl has separate std::thread just for dbus handling
@gjc13 : Correct
@turon : If it can work, defer gio port of ThreadMgr to optimization.
@yufengwangca : Believe there will be conflicts.
@turon : Thought dbus is designed for multiple clients and services on one system
@yufengwangca : Not advised to have multiple dbus clients in one process. Multiple dbus IDs would confuse the system. Not designed for that.
@bukepo : Please share material on those limitations

[yufengwangca]

#1557

[yufengwangca]

This issue can be closed