> >I'm sorry people :) I should have been more specific. Here is
> >what i meant. I'm working on Bluetooth stack for FreeBSD. Everything
> >is implemented in Netgraph. The real device driver nodes are connected
> >to HCI layer. You can talk to any Bluetooth device via HCI layer. It
> >does not really matter what kind of device you have, PC-CARD, serial
> >or USB dongle. They all MUST talk via HCI. So HCI is not really a
> device driver, and, IMO, it is not a pseudo device driver. It sort
> >of looks like /dev/tcp :)
> That's called a "protocol family" in BSD and you access it using
> sockets.

Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a
predefined set of control messages and events that user might send
to the device. L2CAP which is runs over HCI _IS_ a network protocol
and it is implemented in AF_BLUETOOTH protocol family. So application
can say s = socket(AF_BLUETOOTH, SOCK_SEQ, BTPROTO_L2CAP) and then
bind(s) and connect(s).

> Based on what little I know about "Blåtand" it will be much easier
> to work with as a socket than as a /dev/bla entry.
> >Currently there is a single "control" hook for every HCI node. Control
> >application connects to the hook and sends HCI commands and receives
> >HCI events. It does work, but once the hook is connected, nobody else
> >can connect to the same hook. That is a limitation, IMO. It would 
> >really be nice to have several control applications. For example,
> This is exactly the kind of semantics sockets offer you.
> >2) Raw HCI sockets
> >
> >   The problem here is how to identify device, i.e. what to put
> >   into sockaddr? Netgraph node name? May be not a good choice,
> >   because it can be changed at any time. Device BD_ADDR? Does not
> >   work also, because in order to get BD_ADDR you must send HCI
> >   command to the device.
> Well, many TCP clients don't care about the name, so they ask
> for INADDR_ANY and get whatever the kernel feels like giving them,
> you could do the same and have the kernel hand out random numbers.

Again, i have to ask specific device on _HCI_ layer. Here is an
example. User plugged the card. Now HCI layer MUST query the card
and ask 

- what is the BD_ADDR (MAC) ?
- what are the capabilities of the device?
- what is the size of the data buffer?
- etc.

HCI layer _has_ all this commands defined. In fact control application
sends several HCI commands to the device to initialze it. After
device is connected to the stack - no problem - you now can use
BD_ADDR in sockaddr and do whatever you want to do.


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to