Hi Vinicius,
I am breaking this out into a new conversation.
How about we create a new parameter to g_attrib_send, which is a boolean
that indicates wether or not the command being sent may be the start (or
continuation) of a Compound GATT procedure?
If this flag is TRUE, then when gattrib.c creates the command record for
it, it will see if it is continuing a prior procedure, and if so add it
to the head of the queue. Perhaps even *replace* the current head, which
would presumably be recognized as the original command.
This would allow it to reuse the Command ID (allowing the upper layers
to cancel as needed) and ensure the single-threaded intent of compound
GATT procedures.
An additional gattrib.c API could then be added which must be called at
the conclusion of all compound GATT procedures. This new API would
perform final clean-up on the procedure, including allowing the next
(following) items in the command queue to be serviced.
Your Thoughts?
--
Brian Gix
bgix@xxxxxxxxxxxxxx
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
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
