On Thu, Sep 30, 2010 at 4:39 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Claudio, > > On Wed, Sep 29, 2010, Claudio Takahasi wrote: >> StartDiscovery() triggers all the process. The adapter type: BR/EDR >> only/LE only or dual mode is hidden from the higher layers. >> So, your suggestion it try to hide all discovery details inside the >> hciops as much as possible? > > That was the idea yes, but I'm not 100% sure that it's the best > approach. Another question is also how do we want to represent this with > the new management interface. Should the kernel do it "all" through a > single request from userspace or should userspace control the separate > BR/EDR and LE discoveries. If it's the former, then having a single > adapter_ops callback makes sense. If it's the later then we should > probably have two separate ones. Either way I now realize that to > implement this with a single callback we'd need to have the HCI event > processing moved over to hciops and that's not something that will > happen very quickly. So maybe it's better to have these as two separate > adapter_ops callbacks for now. > > Johan > Another point is: scanning needs to be disabled "actively", it is not possible to inform a scanning length like inquiry, it is necessary to create a timeout to disable the scanning. Joining inquiry and scanning inside a single adapter_ops callback will be hard to control the discovery procedure "states". So for now, I prefer two separate callbacks due the scanning timeout and HCI events processing. However, for the new management interface, one single request seems to be more appropriate but extra requests will be necessary to setup the scan and inquiry parameters. Claudio -- 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
