Re: [Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann <marcel@rvs.uni-bielefeld.de>]

Hi Max,

> >Should we keep the kernel inquiry interface? The kernel inside inquiry
> >cache is a nice thing and works in the background like a charm :)
> You mean HCI_INQUIRY ioctl, right ? I'm not sure about that one.
> We'll certainly keep inquiry cache. Cache doesn't really depend on ioctl.

yes, I meant the ioctl. The kernel inquiry cache is a nice thing and
maybe we should provide read only access to it from the userspace.

> >What about the idea to integrate the inquiry into the library or into
> >the Bluetooth master daemon.
> I don't see a need for forwarding inquiry results from a daemon. It can be 
> done in a simple way in the kernel, just like I explained in prev emails
> (ie kernel parsing hci_inquiry command).

My concern is the HCI_INQUIRY ioctl, because it don't really fits the
possibilities and specification details of the inquiry command. But I
don't know what the best way is here and with Bluetooth 1.2 we can also
get the RSSI from an inquiry result.

At the moment I think additional ioctl's for accessing the inquiry cache
will make it possible to use the inquiry command in a more dynamic way:

	- get number of inquiry cache entries
	- copy first n inquiry cache entries to my buffer
	- flush inquiry cache

Comments? Ideas?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel