Re: [PATCH 2/3] Extract service UUIDs from advertising data

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Anderson,

On Thu, Nov 18, 2010, Anderson Lizardo wrote:
> > What's the reason that the get_eir_uuids API is designed so that it can
> > handle a list which already contains elements before calling the
> > function? Since you free the list right after creating the uuids array
> > it seems like this shouldn't happen. Or am I missing something?
> 
> The list is destroyed here just to keep the old semantics for BR/EDR,
> which ignores service UUIDs from previous EIR data.
> 
> For LE devices (as you can see on the following 3/3 patch) we do not
> destroy the previous list when new advertising data is parsed.
> Instead, we "merge" the UUIDs list.

Fair enough. I've pushed the patch upstream now.

> Do you think we can unify semantics of BR/EDR and LE and always merge
> the service UUIDs for both EIR and advertising data?

Yeah, I think that could make sense. Feel free to send a patch for it.

> On the current code, the UUIDs array is always created on each EIR
> data (inside get_eir_uuids()) and destroyed right after the
> DeviceFound signal is emitted. For simplicity, we kept this same
> behavior.
> 
> I agree we can make some optimization here and avoid heap
> allocations/deallocations when UUIDs do not change. One idea might be
> to keep the uuids char* array as well as the GSList on the
> remote_dev_info struct, and only recreate this array if any new UUIDs
> were added to the GSList (this can be identified if the uuidcount has
> changed, because we never delete UUIDs). What do you think?

Yes, that sounds like a good optimization.

Johan