Johan, > -----Original Message----- > From: Johan Hedberg [mailto:johan.hedberg@xxxxxxxxx] > Sent: Tuesday, November 29, 2011 11:15 AM > To: Ganir, Chen > Cc: Andre Guedes; linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2 9/9] Bluetooth: Support LE-Only discovery > procedure > > Hi Chen, > > > Do we really need this kind of functionality? > > Firstly you should realize that this is not about functionality exposed > to the user or applications, but functionality exposed to bluetoothd. > The fact that we have something in the mgmt interface doesn't mean that > it'll automatically be exposed in the D-Bus interface or bluetoothd > internal APIs. > > As for this particular case (allowing bluetoothd to restrict device > discovery to LE or BR/EDR) the reason is the concern that when doing > discovery for a specific profile which is only applicable for BR/EDR or > LE, you really don't want to waste the users time doing the "other" > discovery which will not yield any valuable results. Examples of this > could be discovering devices to send a file over Object Push (BR/EDR > only) or when running a application for a LE profile which utilizes > features only available though an LE radio. > > I'm not completely sure the need for this will be strong enough for > exposing it in the D-Bus API, but not having it in the kernel interface > (mgmt) from the start makes it a lot harder to fix if we do end up > needing it later (as opposed to the D-Bus interface which would "only" > mean doing a new major BlueZ version). > > Johan If this is the case, and we know that for now, we have no need for this, why introduce more complexity ? How will the current GAP device search work ? How will interleaved scanning work ? Will it be triggered from the bluetoothd ? Will it be handled by the kernel ? Chen. -- 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
