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 -- 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
