Date: Mon, 18 May 2009 21:31:17 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update Message-ID: <1242678678.137958.4773.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70905180926x1cb3f79dsad037f06dff4b8c5@mail.gmail.com> References: <E1Lv5La-00058x-HH@smtpbarns01> <bb4a86c70904220909j5d047ce6x6260bd2e87b5b7bd@mail.gmail.com> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <bb4a86c70905140926n488cb2b5x5f5530e01d70bd66@mail.gmail.com> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <bb4a86c70905141140u2b1662fdrf528c157d5fe7c2e@mail.gmail.com> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> <bb4a86c70905151021u2a42dd29m2edce0a011aba838@mail.gmail.com> <1242420574.009085.2429.nullmailer@galant.ukfsn.org> <bb4a86c70905180926x1cb3f79dsad037f06dff4b8c5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1242678678.137958.4773.nullmailer>