Date: Thu, 04 Oct 2001 08:53:58 -0700 From: Maksim Yevmenkin <myevmenk@digisle.net> To: Duncan Barclay <dmlb@dmlb.org> Cc: freebsd-hackers@FreeBSD.ORG, John Kozubik <john@kozubik.com> Subject: Re: bluetooth Message-ID: <3BBC8616.67094EF7@digisle.net> References: <XFMail.011004083438.dmlb@computer.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
Duncan > I might be worth talking to the people at > > http://www.blueaid.com/ Thanks for the info! > Bill Munday has written and architected a number of the Bluetooth stacks > various vendors use. He does free consulting and knows a _lot_ of people > in the Bluetooth world. He is likely to know about other Bluetooth > efforts for Linux. Again thanks for the name :) As far as Linux concern, i'm aware of two BlueTooth stacks for Linux 1) AXIS OpenBT stack (http://sourceforge.net/projects/openbt/) 2) Bluez (http://bluez.sourceforge.net/) (i actually know the Bluez author. Great programmer, we use to work together.) > I can also help out with concepts/overviews etc. I have designed RFICs > for Bluetooth and am part of the SIG writing version 1.2 of the standard > (and no, I didn't do any of version 1.1 so don't hassle me!). Well, i would like to take this opportunity and tell a little bit more about current status :) If anyone feels that it is not appropriate place or time please let me know. [...] > > the implementation is based on Netgraph and supposed to be completely > > optional. The current design goals are: 1) Minimal changes to FreeBSD kernel code. It should be possible to maintain stack outside of FreeBSD code if required. 2) Stack must be optional. Do not want it - do not use it. 3) Stack must be flexible. Parts of the stack must be replaceable. 4) Stack must provide access to all protocol layers. 5) Try to avoid (if possible) kernel threads and try to reduce or eliminate extra overhead on synchronization. 6) Stack must provide option to configure each unit in "special" way to work around possible hardware bugs. 7) Try to stay within Netgraph infrastructure and reuse most of Netgraph tools (ngctl etc). i want to do something different rather than "classic" network stack. That is why i decided to try Netgraph framework. It is highly experimental code (proof of concept, if you will :) So far things looks like this. Please note i'm still working on this and there might be other "oop"es and "gotcha"s :) x x | | User space /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ | | Kernel / | sco | acl \ +--V-----------------V--+ / | | cmd \ | Netgraph HCI node <---------------/--> "btd" | | \ daemon. +----------^------------+ / Controls BlueTooth | drv \ unit | | | right Kernel space / User space +----------V------------+ \ | |---------------/--> | Netgraph "tee" node | righ2left \ "btdump" | |---------------/--> utility +----------^------------+ left2right \ Dumps all packets | left / "a-la" tcpdump | | | hook +----------V------------+ | | | BlueTooth unit driver | | (Netgraph node) | | | +-----------------------+ New instance of a HCI node are created for each BlueTooth unit. The participating nodes are connected as described above. The HCI node exports three hooks: 1) acl - ACL data (Data) 2) sco - SCO data (Voice) 3) cmd - special hook that allows to send HCI commands to the unit. All HCI commands and events are mapped to Netgraph control messages. One HCI command/event - one control message. The "tee" node is used to provide access to raw data and if this is not required may be omitted. The current model is one user space process per BlueTooth unit. However it might be converted to thread per process model. Control daemon "btd" is responsible for initialization and control of the unit. When daemon starts it sends set of HCI commands to recognize unit and then sends another set of HCI commands to perform actual intialization. Results are reported back in form of Netgraph control messages. The initialization sequence may vary depending on specific unit (to work around possible hardware bugs) and daemon must decide if it was successful or not. The control daemon also may implement additional features such as management of pin codes and link keys etc. In the near future there will be L2CAP node that will be attached to "acl" hook. But for now it is possible to implement L2CAP procotol as user space daemon, and then convert it to Netgraph node. The same is true for RFCOMM, SDP and TCP (Telephony Control Protocol :) nodes. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BBC8616.67094EF7>