Hi > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Johan Hedberg > Sent: Tuesday, November 01, 2011 12:07 PM > To: Ilia, Kolominsky > Cc: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: Implementation of name-resolve procedures in mgmtops > > Hi Ilia, > > On Mon, Oct 31, 2011, Ilia, Kolominsky wrote: > > Could you please outline the intended mechanics for the new > > Name-resolve procedures in mgmtops? > > - What is the purpose of Confirm Name command? > > ( I see that you`d added it but not implemented ) > > - What are the main differences in the mechanics between > > the hciops and mgmtops? > > - Are there any changes in user behavior? > > We already discussed this on IRC, but I'll recap here so that it gets > stored in the mailing list archives. This way people can also correct > me > if I remember something wrong about what we agreed in Prague. > > Regarding mgmtops vs hciops, the idea (as long as we hold on to hciops) > is that hciops roughly emulates what the kernel will do when accessed > through the mgmt interface. That also means that the adapter_ops API > should be modeled more or less according to the mgmt interface (e.g. > the > resolve_name callback needs to go and a confirm_name callback needs to > be added). Maybe we should keep resolve_name() method, so the user will be able to perform name resolution for a specific device without triggering the whole discovery process? This will allow more flexibility for the user. > > During a device discovery session the kernel will set the (new) Confirm > Name field in mgmt_ev_device_found to 1 whenever the kernel doesn't > know > if know the name for that device or not. Upon receiving such an event > user-space (bluetoothd) will check its storage and respond with the > (new) Confirm Name command. The field in mgmt_ev_device found would be > set to 1 e.g. for any non-EIR inquiry result for a device we haven't > received a confirm_name command for previously (during the same > discovery session) and for any EIR result which doesn't contain a full > name. > > Each "unknown name" device that user-space tells the kernel about gets > added to a list and once the currently ongoing inquiry finishes the > kernel proceeds with trying to resolve the name for each device in the > list, one at a time. For efficiency, this list should be sorted by > strongest RSSI first so that devices which are with a higher likelihood > closer to us get their names resolved first. The kernel will also wait > a > few seconds (2 sounds like an ok value?) if user space hasn't yet Do we really need to wait here? - if this is to allow human interaction then 2 sec will be not enough anyway, if this is to allow the ack for the last ( the assumption is that the user will decide whether to ack or not on more or less sequential way ) discovered device, then, 2 sec is an overkill, so 1 or even 0.5 I think may be enough. > responded with a name confirmation for a device when inquiry finishes. > Once the list of names to be resolved is empty the device discovery is > deemed complete. > > 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 Regards, Ilia -- 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
