Looking through code examples, it looks like hci_get_route(NULL) is generally used to get a device id for a Bluetooth device on the local machine. That's fine, and I can understand that. My confusion, I suppose, would only matter on a system that has more than one Bluetooth device, and where the argument to hci_get_route() is non-NULL. The source code for hci.c shows the following implementation:
int hci_get_route(bdaddr_t *bdaddr)
{
int dev_id;
dev_id = hci_for_each_dev(HCI_UP, __other_bdaddr,
(long) (bdaddr ? bdaddr : BDADDR_ANY));
if (dev_id < 0)
dev_id = hci_for_each_dev(HCI_UP, __same_bdaddr,
(long) (bdaddr ? bdaddr : BDADDR_ANY));
return dev_id;
}
I won't copy the whole code of hci_for_each_dev(), __other_bdaddr(), or __same_bdaddr() here, but in short this function, if provided with a non-NULL bdaddr_t*, will try first to find a device with an address that does not match the address provided, and then, only after that fails, selects the device with the matching address. I looked back at the commit that introduced this function, and it's slightly different, but still uses __other_bdaddr:
int hci_get_route(bdaddr_t *bdaddr)
{
if (bdaddr)
return hci_for_each_dev(HCI_UP, __other_bdaddr, (long) bdaddr);
else
return hci_for_each_dev(HCI_UP, NULL, 0);
}
Even this initial version appears, very intentionally, to do the same thing, it just doesn't include the backup check using __same_bdaddr.
Seeing as there is no documentation for this function (that I can find), it seems that a novice user of this library would expect the bdaddr_t* argument to be used to select the device, so my question is, why does it do the exact opposite, preferring any other device before selecting the device with the matching address?
