libhci update

[Iain Hibbert]

On Mon, 18 May 2009, Maksim Yevmenkin wrote:

> in any case, state parameter should be checked first before accessing
> anything else. i'm guessing we need to define bluetooth device states
> independent of implementation. in freebsd we have connected, initialized
> and ready = connected+ready states. connected means that device hook is
> connected (i.e. device is present). initialized means that we run
> initialization sequence (get bd_addr, features, etc.).

Mm, I have a bunch of device flags for this situation. I followed the
example of a network interface where it must be enabled to work so you can
turn it off and save power (for PCMCIA at least it does that, in USB I
don't know if there is a way to turn off the power)

#define BTF_UP			(1<<0)	/* unit is up */
#define BTF_RUNNING		(1<<1)	/* unit is running */
#define BTF_INIT_BDADDR		(1<<5)	/* waiting for bdaddr */
#define BTF_INIT_BUFFER_SIZE	(1<<6)	/* waiting for buffer size */
#define BTF_INIT_FEATURES	(1<<7)	/* waiting for features */
#define BTF_POWER_UP_NOOP	(1<<8)	/* should wait for No-op on power up */
#define BTF_INIT_COMMANDS	(1<<9)	/* waiting for supported commands */

#define BTF_INIT		(BTF_INIT_BDADDR	\
				| BTF_INIT_BUFFER_SIZE	\
				| BTF_INIT_FEATURES	\
				| BTF_INIT_COMMANDS)

but that can be easily converted to other values

(btw BlueZ/Linux seems to provide UP/INIT/RUNNING flags)

> > Mm, I've fixed bt_devinfo() so it will work for inactive devices, will
> > think about the devenum some more.

I fixed that now, it just does the best it can - if the device is not
enabled you get an unbound socket (but since sending stuff wouldn't work
anyway it probably doesn't matter for now :)

> > - in bt_devany_cb() you should perhaps make sure that the device is an
> > enabled one?
>
> what does 'enabled' means?

I guess it should wait until it finds a 'connected' device then. Otherwise
if there are N devices but the first has just been plugged in, such an
inquiry may fail. (its one of those edge cases :)

{

	if ((di->state & BTF_UP)) {
		memcpy(arg, di->devname, HCI_DEVNAME_SIZE);
		return 1;
	}

	return 0;
}

> > - I'm thinking that bt_devopen() should have an options argument, in order
> > to pre-set any options such as TIMESTAMP, DIRECTION etc (even NBIO)
> > which will get around the differences in API for that (BlueZ had a weird
> >  thing with not supporting SOL_SOCKET, SO_TIMESTAMP even though Linux
> >  does I don't know if they fixed it yet)
>
> maybe bt_dev{get,set}opts() ?

Well, I think a flags/options arg is simpler (very rare would anybody want
to change the options during the lifetime of a socket?)

Actually, I thought about this some more and found another problem in that
bt_devrecv() does not have any way to extract the control messages.

> > - in bt_devinquiry() we accept (dev == NULL) to mean any device, should
> > that happen in bt_devopen() too?
>
> we could.
>
> > - along this line I wonder if it is possible open a promiscuous socket
> > (eg as used by hcidump) instead of any particular device? (could be
> > dev==NULL I guess, or a PROMISCUOUS option?) I'm not sure how Linux
> > works but on NetBSD you must explicitly bind to 00:00:00:00:00:00 to
> >  get that behaviour (IIRC FreeBSD gives it to you by default but I was
> >  paranoid :)
>
> right, in freebsd we just don't bind socket to anything and use filter
> to enable all event/packets/etc. this is how we get promiscuous
> socket.

The thing I didn't like about that is that you might get messages that you
think came from your bound device but in fact they came from some other..

> perhaps bt_devopen(NULL) should mean create non-bound socket?

Hmm, need to think about it some - again, bt_devrecv() does not have any
way to retreive the socket address, so it would need to be declared that
the descriptor bt_devopen() returns is a socket handle and using
sendto/recvfrom/sendmsg/recvmsg etc is ok in that case. That means that a
system that uses a device node instead of a socket for HCI cannot use the
API. Perhaps not a problem?

I prefer bt_devopen(NULL) to mean 'receive messages from all devices'
rather than 'find first device' though..

iain