> >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. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
