From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
To: Brian Gix <bgix@codeaurora.org>
Cc: linux-bluetooth@vger.kernel.org, padovan@profusion.mobi,
rshaffer@codeaurora.org
Subject: Re: [PATCH 1/1] Support for reading long Characteristic Values.
Date: Mon, 13 Dec 2010 15:39:51 -0300 [thread overview]
Message-ID: <20101213183951.GB7549@eris> (raw)
In-Reply-To: <1292261066-28100-3-git-send-email-bgix@codeaurora.org>
On 09:24 Mon 13 Dec, Brian Gix wrote:
> Modify existing gatt_read_char() function support the reading of
> attributes (specifically Characteristic Values) that are longer than
> the MTU would otherwise allow. When a result to an ATT_OP_READ_REQ
> is received, it will be passed to the requester as always if the total
> result was shorter than the Default MTU (23). Any results equal to or
> longer will cause a series of READ_BLOB requests to be made, with the
> additional results built up until the end of the Attribute is detected.
> The full result will then be passed to the original requester.
>
> The end of the Attribute is detected by either a successful result to
> the READ_BLOB request that is shorter than the Default MTU, or by an
> error result that indicates that a read is being attempted beyond the
> length of the attribute, or that the Attribute wasn't "Long".
>
> This patch is dependant on the earlier patch:
> 0001-Implempent-READ_BLOB-encoding-for-ATT.patch
>
> The packet composed conforms to the Bluetooth Core v4.0 specification.
>
> Brian Gix
> bgix@codeaurora.org
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
>
> ---
> attrib/gatt.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 112 insertions(+), 2 deletions(-)
>
> diff --git a/attrib/gatt.c b/attrib/gatt.c
> index bca8b49..d888f1d 100644
> --- a/attrib/gatt.c
> +++ b/attrib/gatt.c
> @@ -97,15 +97,125 @@ guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
> pdu, plen, func, user_data, NULL);
> }
>
> +struct read_long_data {
> + GAttrib *attrib;
> + GAttribResultFunc func;
> + gpointer user_data;
> + guint8 *result_data;
> + guint16 result_len;
I would call result_data "buffer" (or something like it) and result_len "size"
(or total). What do you think?
> + guint16 handle;
> +};
> +
> +static void read_blob_helper(guint8 status, const guint8 *res_pdu,
> + guint16 res_len, gpointer user_data)
> +{
> + struct read_long_data *long_read = user_data;
> + uint8_t pdu[ATT_DEFAULT_MTU];
> + guint8 *tmp;
> + guint16 plen;
> + guint ret_val;
> +
> + if (status == ATT_ECODE_ATTR_NOT_LONG ||
> + status == ATT_ECODE_INVALID_OFFSET) {
> + status = 0;
> + goto done;
> + }
> +
> + if (status != 0 || res_len == 1)
> + goto done;
> +
> + tmp = g_try_realloc(long_read->result_data,
> + long_read->result_len + res_len - 1);
> +
> + if (tmp == NULL) {
> + status = ATT_ECODE_INSUFF_RESOURCES;
> + goto done;
> + }
> +
> + memcpy(&tmp[long_read->result_len], &res_pdu[1], res_len-1);
It should be "res - 1".
> + long_read->result_data = tmp;
> + long_read->result_len += res_len-1;
Same here.
> +
> + if (res_len < ATT_DEFAULT_MTU)
> + goto done;
> +
> + plen = enc_read_blob_req(long_read->handle, long_read->result_len-1,
And here.
> + pdu, sizeof(pdu));
> + ret_val = g_attrib_send(long_read->attrib, ATT_OP_READ_BLOB_REQ, pdu,
> + plen, read_blob_helper, long_read, NULL);
> +
> + if (ret_val != 0)
> + return;
> +
> + status = ATT_ECODE_INSUFF_RESOURCES;
> +
> +done:
> + long_read->func(status, long_read->result_data, long_read->result_len,
> + long_read->user_data);
> + g_free(long_read->result_data);
> + g_free(long_read);
> +}
> +
> +static void read_char_helper(guint8 status, const guint8 *res_pdu,
> + guint16 res_len, gpointer user_data)
> +{
> + struct read_long_data *long_read = user_data;
> + uint8_t pdu[ATT_DEFAULT_MTU];
> + guint16 plen;
> + guint ret_val;
> +
> + if (status != 0 || res_len < ATT_DEFAULT_MTU)
> + goto done;
> +
> + long_read->result_data = g_malloc(res_len);
> +
> + if (long_read->result_data == NULL)
> + goto done;
> +
> + memcpy(long_read->result_data, res_pdu, res_len);
> + long_read->result_len = res_len;
> +
> + plen = enc_read_blob_req(long_read->handle, res_len-1, pdu,
> + sizeof(pdu));
> + ret_val = g_attrib_send(long_read->attrib, ATT_OP_READ_BLOB_REQ,
> + pdu, plen, read_blob_helper, long_read, NULL);
g_attrib_send() returns an command id (something that could be used to cancel
the command later, if needed), so I think it would make more sense to call
ret_val "id" or just "ret". And thinking about it, I guess that the "res_"
prefix doesn't add much meaning to "res_pdu" and "res_len". Do you agree?
> +
> + if (ret_val != 0)
> + return;
> +
> + status = ATT_ECODE_INSUFF_RESOURCES;
> +
> +done:
> + long_read->func(status, res_pdu, res_len, long_read->user_data);
If g_attrib_send() fails, load_read->result_data may be leaking here.
> + g_free(long_read);
> +}
> +
> guint gatt_read_char(GAttrib *attrib, uint16_t handle, GAttribResultFunc func,
> gpointer user_data)
> {
> uint8_t pdu[ATT_DEFAULT_MTU];
> guint16 plen;
> + guint ret_val;
> + struct read_long_data *long_read;
> +
> + long_read = g_try_new0(struct read_long_data, 1);
> +
> + if (long_read == NULL)
> + return 0;
> +
> + long_read->attrib = attrib;
> + long_read->func = func;
> + long_read->user_data = user_data;
> + long_read->handle = handle;
>
> plen = enc_read_req(handle, pdu, sizeof(pdu));
> - return g_attrib_send(attrib, ATT_OP_READ_REQ, pdu, plen, func,
> - user_data, NULL);
> + ret_val = g_attrib_send(attrib, ATT_OP_READ_REQ, pdu, plen,
> + read_char_helper, long_read, NULL);
> +
> + if (ret_val == 0)
> + g_free(long_read);
> +
> + return ret_val;
> }
>
> guint gatt_write_char(GAttrib *attrib, uint16_t handle, uint8_t *value,
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
next prev parent reply other threads:[~2010-12-13 18:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-13 17:24 [PATCH 0/2] Implement Long reads for GATT/ATT Brian Gix
2010-12-13 17:24 ` [PATCH 1/1] Implempent READ_BLOB encoding for ATT Brian Gix
2010-12-13 18:15 ` Vinicius Costa Gomes
2010-12-13 17:24 ` [PATCH 1/1] Support for reading long Characteristic Values Brian Gix
2010-12-13 18:39 ` Vinicius Costa Gomes [this message]
2010-12-13 19:56 ` Brian Gix
2010-12-13 20:33 ` Vinicius Costa Gomes
2010-12-13 21:33 ` Brian Gix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101213183951.GB7549@eris \
--to=vinicius.gomes@openbossa.org \
--cc=bgix@codeaurora.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=padovan@profusion.mobi \
--cc=rshaffer@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).