On Thu, 2012-05-24 at 11:29 +0300, Luiz Augusto von Dentz wrote: > Hi Tanu, > > On Wed, May 23, 2012 at 4:11 PM, Tanu Kaskinen <tanu.kaskinen at digia.com> wrote: > > On Wed, 2012-05-23 at 12:20 +0300, Luiz Augusto von Dentz wrote: > >> Btw, are you sure this is a problem? We can have the same address in > >> different devices if they are paired with different adapters, > >> otherwise it is a bug and we should be able to fix it. > > > > Thanks for the information. I had the assumption[1] that the device > > addresses should be unique, but if they're not, the code that I've > > written is certainly broken. > > > > [1] I tried to verify my assumption first by asking on the #bluez irc > > channel, and after getting no responses, I checked the bluetoothd code > > and it seemed like the addresses would be guaranteed to be unique. The > > device objects were put in a map with the address as the key, so there > > could be no duplicates, but I guess I missed the fact that there are > > multiple of those maps, one for each adapter. > > The object path is guaranteed to be unique if you need something as a > hash table key or something like that use it instead of the address, > but note that object path might change over time due to reboot or > bluetoothd being restarted, so you need to cleanup. Yep, I know that. The device address is used for implementing the "address" module argument for module-bluetooth-device, and that requires a way to look up a device by its address. Currently that lookup is done by linearly iterating through the devices and picking the first one that matches, and I thought that having a hashmap for that lookup would be nicer, but that has now turned out to be a bad idea. Otherwise than that use case, I think there's no need to look up devices by their address - the object path is used instead. -- Tanu
