Hello again, > > So I could be convinced to add new functions to read/write the limit > > from within an application itself. So that it can be changed without > > re-compiling the library. Feel free to propose a patch. > I will see what i can do. What is needed is probably a > hci_set_max_devices() call. Then hcitool could call that with the number > of devices needed. After some time looking at it more closely, i can see that the real problem is not in hcilib, but in the stack itself. The real problem is that there is no way of getting the actual number of devices with reading out all of them... and thereby allocating space for MAX devices (which could be endless). Chicken and Egg situation. What is really needed is an ioctl to get the current count. This could be done by: a) A new IOCTL called HCIGETDEVCOUNT that returns the device count. or b) Modifying HCIGETDEVLIST to return the device count (dev_num) if the input count (dev_num) is zero (without actually returning the devices). This would be backward compatible, as zero is not a valid input today. Is any of this acceptable? Please advise what solutions could be acceptable. This would allow for hci_for_each_dev (and in turn the stack via IOCTL) to use less resources, and to support more devices. This could deprecate the need for MAX_HCI_DEV altogether, as it is not used anywhere else in the lib. There is of-course allot of other software using that constant, but maybe removing it over time would be good. It gives the user of the lib a false idea of a non-existing limitation. Thanks, /Pedro -- 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
