2014-03-25 14:34:38

by Ravi kumar Veeramally

[permalink] [raw]
Subject: [RFC 0/3] Add HDP .register_application method

Due to limited IPC_MTU and variable length of
fields from 'bthl_reg_param_t *', it is difficult to put them
in single command and send though IPC. So we split this command
to multiple calls. First command will be called with opcode of
HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
Later command will be called with opcode of
HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
number_of_mdeps times. Daemon (android/health) side it will
process after it received all data and response will be sent
along with last call of HAL_OP_HEALTH_MDEP.

This avoids increasing value of IPC_MTU and mainly because of
optional parameters in 'bthl_reg_param_t'. Incase of unfilled
optional parameters, fixed size arrays in hal commands will be
empty.

Ravi kumar Veeramally (3):
android/hal-ipc-api: Add extra command to Health HAL api document
android/hal-msg: Add extra struct for mdep data
android/hal-health: Add HDP .register_application method

android/hal-health.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++-
android/hal-ipc-api.txt | 34 +++++++++++--------
android/hal-msg.h | 37 ++++++++++-----------
3 files changed, 126 insertions(+), 33 deletions(-)

--
1.8.3.2



2014-03-31 08:03:26

by Ravi kumar Veeramally

[permalink] [raw]
Subject: Re: [RFC 0/3] Add HDP .register_application method

ping.

On 03/28/2014 03:48 PM, Ravi kumar Veeramally wrote:
> ping.
>
> On 03/25/2014 04:34 PM, Ravi kumar Veeramally wrote:
>> Due to limited IPC_MTU and variable length of
>> fields from 'bthl_reg_param_t *', it is difficult to put them
>> in single command and send though IPC. So we split this command
>> to multiple calls. First command will be called with opcode of
>> HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
>> Later command will be called with opcode of
>> HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
>> number_of_mdeps times. Daemon (android/health) side it will
>> process after it received all data and response will be sent
>> along with last call of HAL_OP_HEALTH_MDEP.
>>
>> This avoids increasing value of IPC_MTU and mainly because of
>> optional parameters in 'bthl_reg_param_t'. Incase of unfilled
>> optional parameters, fixed size arrays in hal commands will be
>> empty.
>>
>> Ravi kumar Veeramally (3):
>> android/hal-ipc-api: Add extra command to Health HAL api document
>> android/hal-msg: Add extra struct for mdep data
>> android/hal-health: Add HDP .register_application method
>>
>> android/hal-health.c | 88
>> ++++++++++++++++++++++++++++++++++++++++++++++++-
>> android/hal-ipc-api.txt | 34 +++++++++++--------
>> android/hal-msg.h | 37 ++++++++++-----------
>> 3 files changed, 126 insertions(+), 33 deletions(-)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>


2014-03-28 13:48:01

by Ravi kumar Veeramally

[permalink] [raw]
Subject: Re: [RFC 0/3] Add HDP .register_application method

ping.

On 03/25/2014 04:34 PM, Ravi kumar Veeramally wrote:
> Due to limited IPC_MTU and variable length of
> fields from 'bthl_reg_param_t *', it is difficult to put them
> in single command and send though IPC. So we split this command
> to multiple calls. First command will be called with opcode of
> HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
> Later command will be called with opcode of
> HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
> number_of_mdeps times. Daemon (android/health) side it will
> process after it received all data and response will be sent
> along with last call of HAL_OP_HEALTH_MDEP.
>
> This avoids increasing value of IPC_MTU and mainly because of
> optional parameters in 'bthl_reg_param_t'. Incase of unfilled
> optional parameters, fixed size arrays in hal commands will be
> empty.
>
> Ravi kumar Veeramally (3):
> android/hal-ipc-api: Add extra command to Health HAL api document
> android/hal-msg: Add extra struct for mdep data
> android/hal-health: Add HDP .register_application method
>
> android/hal-health.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++-
> android/hal-ipc-api.txt | 34 +++++++++++--------
> android/hal-msg.h | 37 ++++++++++-----------
> 3 files changed, 126 insertions(+), 33 deletions(-)
>


2014-03-25 14:34:40

by Ravi kumar Veeramally

[permalink] [raw]
Subject: [RFC 2/3] android/hal-msg: Add extra struct for mdep data

Defined extra structure for MDEP data which is required for Register
Application. Also updated Opcodes for rest.
---
android/hal-msg.h | 37 ++++++++++++++++++-------------------
1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/android/hal-msg.h b/android/hal-msg.h
index b7fa8fc..44a72b0 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -383,37 +383,36 @@ struct hal_cmd_pan_disconnect {
uint8_t bdaddr[6];
} __attribute__((packed));

-struct hal_string {
- uint8_t len;
- uint8_t data[0];
-};
-
#define HAL_OP_HEALTH_REG_APP 0x01
struct hal_cmd_health_reg_app {
- struct hal_string app_name;
- struct hal_string provider_name;
- struct hal_string service_name;
- struct hal_string service_descr;
- uint8_t num_of_mdep;
+ uint8_t num_of_mdep;
+ uint16_t app_name_off;
+ uint16_t provider_name_off;
+ uint16_t service_name_off;
+ uint16_t service_descr_off;
+ uint16_t len;
+ uint8_t data[0];
+} __attribute__((packed));

- struct {
- uint8_t role;
- uint8_t data_type;
- uint8_t channel_type;
- struct hal_string descr;
- } mdep_cfg[0];
+#define HAL_OP_HEALTH_MDEP 0x02
+struct hal_cmd_health_mdep {
+ uint8_t role;
+ uint8_t data_type;
+ uint8_t channel_type;
+ uint16_t descr_len;
+ uint8_t descr[0];
} __attribute__((packed));

struct hal_rsp_health_reg_app {
uint16_t app_id;
} __attribute__((packed));

-#define HAL_OP_HEALTH_UNREG_APP 0x02
+#define HAL_OP_HEALTH_UNREG_APP 0x03
struct hal_cmd_health_unreg_app {
uint16_t app_id;
} __attribute__((packed));

-#define HAL_OP_HEALTH_CONNECT_CHANNEL 0x03
+#define HAL_OP_HEALTH_CONNECT_CHANNEL 0x04
struct hal_cmd_health_connect_channel {
uint16_t app_id;
uint8_t bdaddr[6];
@@ -424,7 +423,7 @@ struct hal_rsp_health_connect_channel {
uint16_t channel_id;
} __attribute__((packed));

-#define HAL_OP_HEALTH_DESTROY_CHANNEL 0x04
+#define HAL_OP_HEALTH_DESTROY_CHANNEL 0x05
struct hal_cmd_health_destroy_channel {
uint16_t channel_id;
} __attribute__((packed));
--
1.8.3.2


2014-03-25 14:34:41

by Ravi kumar Veeramally

[permalink] [raw]
Subject: [RFC 3/3] android/hal-health: Add HDP .register_application method

Implementation of register_application is different compared
to other apis. Due to limited IPC_MTU and variable length of
fields from 'bthl_reg_param_t *', it is difficult to put them
in single command and send though IPC. So we split this command
multiple calls. First command will be called with opcode of
HAL_OP_HEALTH_REG_APP with 'struct hal_cmd_health_reg_app' data.
Later command will be called with opcode of
HAL_OP_HEALTH_MDEP with 'struct hal_cmd_health_mdep' data for
number_of_mdeps times. Daemon (android/health) side it will
process after it received all data and response will be sent
along with last call of HAL_OP_HEALTH_MDEP.

This avoids increasing value of IPC_MTU and mainly because of
optional parameters in 'bthl_reg_param_t'. Incase of unfilled
optional parameters, fixed size arrays in hal commands will be
empty.
---
android/hal-health.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 87 insertions(+), 1 deletion(-)

diff --git a/android/hal-health.c b/android/hal-health.c
index e6fe65a..bfd5779 100644
--- a/android/hal-health.c
+++ b/android/hal-health.c
@@ -38,6 +38,92 @@ static bool interface_ready(void)
static const struct hal_ipc_handler ev_handlers[] = {
};

+static bt_status_t register_application(bthl_reg_param_t *reg, int *app_id)
+{
+ uint8_t buf[IPC_MTU];
+ struct hal_cmd_health_reg_app *cmd = (void *) buf;
+ struct hal_cmd_health_mdep *mdep = (void *) buf;
+ struct hal_rsp_health_reg_app rsp;
+ size_t rsp_len = sizeof(rsp);
+ bt_status_t status;
+ uint16_t off, len;
+ int i;
+
+ DBG("");
+
+ if (!interface_ready())
+ return BT_STATUS_NOT_READY;
+
+ if (!reg || !app_id || !reg->application_name)
+ return BT_STATUS_PARM_INVALID;
+
+ memset(buf, 0, IPC_MTU);
+
+ cmd->num_of_mdep = reg->number_of_mdeps;
+
+ off = 0;
+ cmd->app_name_off = off;
+ len = strlen(reg->application_name);
+ memcpy(cmd->data, reg->application_name, len);
+ off += len;
+
+ if (reg->provider_name) {
+ len = strlen(reg->provider_name);
+ cmd->provider_name_off = off;
+ memcpy(cmd->data + off, reg->provider_name, len);
+ off += len;
+ } else {
+ cmd->provider_name_off = 0;
+ }
+
+ if (reg->srv_name) {
+ len = strlen(reg->srv_name);
+ cmd->service_name_off = off;
+ memcpy(cmd->data + off, reg->srv_name, len);
+ off += len;
+ } else {
+ cmd->service_name_off = 0;
+ }
+
+ if (reg->srv_desp) {
+ len = strlen(reg->srv_desp);
+ cmd->service_descr_off = off;
+ memcpy(cmd->data + off, reg->srv_desp, len);
+ off += len;
+ } else {
+ cmd->service_descr_off = 0;
+ }
+
+ cmd->len = off;
+ status = hal_ipc_cmd(HAL_SERVICE_ID_HEALTH, HAL_OP_HEALTH_REG_APP,
+ sizeof(*cmd) + cmd->len, &cmd, 0, NULL, NULL);
+
+ if (status != HAL_STATUS_SUCCESS)
+ return status;
+
+ for (i = 0; i < reg->number_of_mdeps; i++) {
+ memset(buf, 0, IPC_MTU);
+ mdep->role = reg->mdep_cfg[i].mdep_role;
+ mdep->data_type = reg->mdep_cfg[i].data_type;
+ mdep->channel_type = reg->mdep_cfg[i].channel_type;
+ mdep->descr_len = strlen(reg->mdep_cfg[i].mdep_description);
+ memcpy(mdep->descr, reg->mdep_cfg[i].mdep_description,
+ mdep->descr_len);
+
+ status = hal_ipc_cmd(HAL_SERVICE_ID_HEALTH, HAL_OP_HEALTH_MDEP,
+ sizeof(*mdep) + mdep->descr_len,
+ buf, &rsp_len, &rsp, NULL);
+
+ if (status != HAL_STATUS_SUCCESS)
+ return status;
+
+ }
+
+ *app_id = rsp.app_id;
+
+ return status;
+}
+
static bt_status_t unregister_application(int app_id)
{
struct hal_cmd_health_unreg_app cmd;
@@ -149,7 +235,7 @@ static void cleanup(void)
static bthl_interface_t health_if = {
.size = sizeof(health_if),
.init = init,
- .register_application = NULL,
+ .register_application = register_application,
.unregister_application = unregister_application,
.connect_channel = connect_channel,
.destroy_channel = destroy_channel,
--
1.8.3.2


2014-03-25 14:34:39

by Ravi kumar Veeramally

[permalink] [raw]
Subject: [RFC 1/3] android/hal-ipc-api: Add extra command to Health HAL api document

Defined extra command for MDEP data which is required for Register
Application command. Also updated Opcode for rest of the commands.
---
android/hal-ipc-api.txt | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 5613e85..08b035d 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1125,28 +1125,36 @@ Commands and responses:

Opcode 0x01 - Register Application command/response

- Command parameters: Application name (string)
- Provider name (string)
- Service name (string)
- Service description (string)
- Number of MDEP (1 octet)
- MDEP Role # (1 octet)
- Data type # (1 octet)
- Channel type # (1 octet)
- MDEP description # (string)
- ...
+ Command parameters: Number of MDEP (1 octet)
+ Application name offset (2 octets)
+ Provider name offset (2 octets)
+ Service name offset (2 octets)
+ Service description offset (2 octets)
+ Data length (2 octets)
+ Data (data length)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Register Application MDEP data command/response
+
+ Command parameters: MDEP Role (1 octet)
+ Data type (1 octet)
+ Channel type (1 octet)
+ MDEP description length (2 octets)
+ MDEP description (MDEP desciption length)
Response parameters: Application ID (2 octets)

In case of an error, the error response will be returned.

- Opcode 0x02 - Unregister Application command/response
+ Opcode 0x03 - Unregister Application command/response

Command parameters: Application ID (2 octets)
Response parameters: <none>

In case of an error, the error response will be returned.

- Opcode 0x03 - Connect Channel command/response
+ Opcode 0x04 - Connect Channel command/response

Command parameters: Application ID (2 octets)
Remote address (6 octets)
@@ -1155,7 +1163,7 @@ Commands and responses:

In case of an error, the error response will be returned.

- Opcode 0x04 - Destroy Channel command/response
+ Opcode 0x05 - Destroy Channel command/response

Command parameters: Channel ID (2 octets)
Response parameters: <none>
--
1.8.3.2