Hi Andrei, On Sun, Nov 17, 2013 at 8:39 PM, Andrei Emeltchenko <andrei.emeltchenko.news@xxxxxxxxx> wrote: > Hi Szymon, > > On Sat, Nov 16, 2013 at 4:13 PM, Szymon Janc <szymon.janc@xxxxxxxxx> wrote: >> >> Register handlers on service init. Since this requires all handlers to >> be registered (unknown opcode is considered IPC error) missing handlers >> stubs are provided. >> --- >> android/hal-bluetooth.c | 223 ++++++++++++++++++++++++++++++------------------ >> android/hal.h | 1 - >> 2 files changed, 142 insertions(+), 82 deletions(-) >> >> diff --git a/android/hal-bluetooth.c b/android/hal-bluetooth.c >> index 078d537..2ec7c10 100644 >> --- a/android/hal-bluetooth.c >> +++ b/android/hal-bluetooth.c >> @@ -35,7 +35,7 @@ static const bt_callbacks_t *bt_hal_cbacks = NULL; >> *pe = *((uint8_t *) (hal_prop->val)); \ >> } while (0) >> >> -static void handle_adapter_state_changed(void *buf) >> +static void handle_adapter_state_changed(void *buf, uint16_t len, int fd) > > Why do we need fd here and in all other places? Who uses it? This is needed for health HAL for bthl_channel_state_callback callback. But since this seems to be the only user for that, this can be removed from callback prototype and a getter function could be added to obtain fd in notification handler (we do process one notification at time after all). Opinions? -- BR Szymon Janc -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
