Home | History | Annotate | only in /hardware/interfaces/wifi/1.2/default
Up to higher level directory
NameDateSize
android.hardware.wifi@1.0-service.rc21-Aug-2018173
Android.mk21-Aug-20183.3K
hidl_callback_util.h21-Aug-20183.8K
hidl_return_util.h21-Aug-20184.6K
hidl_struct_util.cpp21-Aug-2018107.9K
hidl_struct_util.h21-Aug-20188.3K
hidl_sync_util.cpp21-Aug-20181.1K
hidl_sync_util.h21-Aug-20181.2K
OWNERS21-Aug-201838
ringbuffer.cpp21-Aug-20181.5K
ringbuffer.h21-Aug-20181.4K
service.cpp21-Aug-20181.9K
tests/21-Aug-2018
THREADING.README21-Aug-20181.9K
wifi.cpp21-Aug-20187.7K
wifi.h21-Aug-20183.3K
wifi_ap_iface.cpp21-Aug-20183.5K
wifi_ap_iface.h21-Aug-20182.3K
wifi_chip.cpp21-Aug-201856K
wifi_chip.h21-Aug-201811.7K
wifi_feature_flags.cpp21-Aug-20181.8K
wifi_feature_flags.h21-Aug-20181.2K
wifi_legacy_hal.cpp21-Aug-201859.2K
wifi_legacy_hal.h21-Aug-201818.3K
wifi_legacy_hal_stubs.cpp21-Aug-20186.6K
wifi_legacy_hal_stubs.h21-Aug-20181.1K
wifi_mode_controller.cpp21-Aug-20182.5K
wifi_mode_controller.h21-Aug-20181.9K
wifi_nan_iface.cpp21-Aug-201836.2K
wifi_nan_iface.h21-Aug-20187.2K
wifi_p2p_iface.cpp21-Aug-20182.1K
wifi_p2p_iface.h21-Aug-20181.9K
wifi_rtt_controller.cpp21-Aug-201811K
wifi_rtt_controller.h21-Aug-20184.4K
wifi_sta_iface.cpp21-Aug-201826.4K
wifi_sta_iface.h21-Aug-20187.7K
wifi_status_util.cpp21-Aug-20183.7K
wifi_status_util.h21-Aug-20181.5K

THREADING.README

      1 Vendor HAL Threading Model
      2 ==========================
      3 The vendor HAL service has two threads:
      4 1. HIDL thread: This is the main thread which processes all the incoming HIDL
      5 RPC's.
      6 2. Legacy HAL event loop thread: This is the thread forked off for processing
      7 the legacy HAL event loop (wifi_event_loop()). This thread is used to process
      8 any asynchronous netlink events posted by the driver. Any asynchronous
      9 callbacks passed to the legacy HAL API's are invoked on this thread.
     10 
     11 Synchronization Concerns
     12 ========================
     13 wifi_legacy_hal.cpp has a bunch of global "C" style functions to handle the
     14 legacy callbacks. Each of these "C" style function invokes a corresponding
     15 "std::function" version of the callback which does the actual processing.
     16 The variables holding these "std::function" callbacks are reset from the HIDL
     17 thread when they are no longer used. For example: stopGscan() will reset the
     18 corresponding "on_gscan_*" callback variables which were set when startGscan()
     19 was invoked. This is not thread safe since these callback variables are
     20 accesed from the legacy hal event loop thread as well.
     21 
     22 Synchronization Solution
     23 ========================
     24 Adding a global lock seems to be the most trivial solution to the problem.
     25 a) All of the asynchronous "C" style callbacks will acquire the global lock
     26 before invoking the corresponding "std::function" callback variables.
     27 b) All of the HIDL methods will also acquire the global lock before processing
     28 (in hidl_return_util::validateAndCall()).
     29 
     30 Note: It's important that we only acquire the global lock for asynchronous
     31 callbacks, because there is no guarantee (or documentation to clarify) that the
     32 synchronous callbacks are invoked on the same invocation thread. If that is not
     33 the case in some implementation, we will end up deadlocking the system since the
     34 HIDL thread would have acquired the global lock which is needed by the
     35 synchronous callback executed on the legacy hal event loop thread.
     36