Hi Marcin,
I'll split your answers to make sure I got everything addressed.
On Thu, Apr 3, 2014 at 3:12 PM, Marcin Kraglak <marcin.kraglak@xxxxxxxxx> wrote:
> about service changed - we have to manage it in daemon.
I could not find on the GATT server HAL API anything that is specific
do Service Changed notifications. So what I expect is that Android HAL
is implementing this internally after the app that implements a
service is closed/uninstalled.
> descriptors are added to characteristics, but api in android looks like this:
> 1. reserve handles for service
> 2. put attributes with reserved handles
>
> Therefore I propose to have method which can "commit" constructed
> service to ba available, something like start service. Similar method
> is present in android hal API.
So you are referring to the separate Add Service and Start Service
commands right? I agree we can have a separate commit procedure, at
least to allow concurrent applications registering services at the
same time. I'll include that on my RFC (should send tomorrow).
> About reallocating attributes to new handles - Android doesn't provide
> API to inform upper layer that we changed attribute's handle. I think
> if we want allocate handles for service, we should first look for
> 'holes' between existing services, and put it if there is available
> space. Therefore I proposed to declare num of handles needed for
> service while creating service.
This is aligned with the need for a "commit" operation so we allow
concurrent construction of services (see above). So I agree with you
on the need to pre-allocate a number of handles.
Regarding finding holes on the database, we can make it more efficient
if we keep track of free ranges in a separate structure, so we don't
need to traverse the attribute list every time.
> Creating groups looks good, but what will happen if two applications
> will start creating services in the same time, without declaring
> number of needed handles? We will probably need to 'reallocate' one of
> them and assign new handles. And Android won't handle it.
The attribute group concept is just a fancy generic name for services
and characteristics (taken from the Spec). So you can do the following
operations with the same gatt_db_add():
- Add a new service
- Add a characteristic to a service
- Add a descriptor to a characteristic
The other option is to have separate functions for these operations
(and a gatt_db_remove_service()).
I'll drop the "resize_group" function as it is unnecessary for now (if
we pre-allocate the range like described above).
>
> Idea of gatt-db which can be reused in both daemons is fine for me.
> Question is if existing skeleton of gatt.h/c is anything more than db?
The current upstream code indeed has only DB handling functions. But
we will introduce other code on that file that is not usable for
Android, so that's why I'm proposing factoring the database management
part to src/shared/gatt-db.{c,h}. You can think of src/gatt.c (in
future) as the equivalent to android/gatt.c (but in Linux we need to
do a lot more than in Android).
>
> @Anderson, did it clarify anything about android requirements?
I still have a few specific questions on Android side:
1) How is the "permissions" parameters for add characteristic/descriptor define?
2) How these permissions should be checked?
3) If you look at the "Add Descriptor" command, you do not provide a
characteristic declaration handle to it, only a service declaration
handle. How does it know to which characteristic to add the
descriptor?
Best Regards,
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
--
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
