Hi Antti, > > I honestly don't know which one is easier. We also have to keep the > > memory constraints in mind. So for how many BD_ADDR does the kernel > > needs to store the flag name resolved already yes/no? With system that > > are running for years, this can get pretty big. > > > > My current take on this (which is not final) is that after inquiry > > complete, the kernel needs to ask userspace to confirm which names to > > resolve. It is an action triggered by the kernel and userspace just > > responds with the result to. So the kernel has full control here. > > > > Can we assume that user space will always reply? Or how long should > kernel wait for confirmation from user space, before ending discovery > procedure and sending Discovering=0 event? the kernel should know if there is an open mgmt socket or not. If there is not, then we should not bother asking userspace. If there is then we have to have a timeout associated with each request. However such a timeout is needed by requests asking for the link key or pin code anyway. So that should be a generic handling in the first place. Regards Marcel -- 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
