[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Stack design and some anoucements

Maksim Krasnyanskiy wrote:

> Hi Folks,
> I'm seeing more and more activity and discussions about Bluetooth stack design, interfaces, etc
> So I thought would be the right time to share some ideas and to make some announcements :).
> Here we go.
> You guys did an excellent job developing your Bluetooth stack but it seems to me that you went in a little bit wrong
> direction (no disrespect :)). For example "char device / ioctl" interface is not a good idea for networking protocols.
> The better way to go is "sockets" which were specifically designed for the networking stuff and allow to easily port
> and reuse tons of existing applications. Also it was not a good idea to implement services like SDP in the
> kernel space which is actually result of the lack of the right interface in the user space.
> I've been working on implementation of the Bluetooth Linux stack here in Qualcomm for a while.
> Our stack is designed and implemented in a completely different way. We should have shared
> that info long time ago, but unfortunately we couldn't do it until all legal issues are clarified.
> Here are some basic design goals that I think are important for the Linux Bluetooth stack.
>         -       Socket interface to lower layers
>         -       Support for multiple Bluetooth devices
>         -       Hot plugging support
>         -       Efficient frame processing (multi threading ,etc)
>         -       Endianess independent
>         -       No unnecessary stuff in the kernel
>         -       Good modularity
> So, here is what we have (from the ground up).
> 1. Kernel part of the stack
> HCI Core (hci.o), features and interfaces:
>         Multiple devices:
>                 Device registration/unregistration
>                 Hot plugging
>                 Abstracted hardware interface. (Doesn't require TTY emulation).
>         Multiple protocols:
>                 Registration/unregistration for the upper protocols(currently L2CAP only).
>         HCI sockets:
>                 Raw sockets
>                 Raw HCI frames
>                 IOCTLs to control devices
>                 Sniffing
>         Multi threaded frame processing:
>                 3 threads per device (RX, TX, CMD)
>         Device modes:
>                 Normal - HCI Core does event processing, notifications and data delivery to upper protocols.
>                 Raw - Device controlled by application. No event processing, notifications, etc.
>         Inquiry cache:
>                 Per device cache of inquiry responses.
>                 Used for establishing connections.
>         Connection scheduler:
>                 Per device connection hash
>                 Round robin scheduling between connections
> HCI USB driver (hci_usb.o). Based on the original driver in 2.4.x however ~70% of the code has been re-written.
> Uses HCI Core interface to register/unregister devices. Delivers complete HCI frames to the core.
> HCI UART driver (hci_uart.o). Uses HCI Core interface to register/unregister devices.
> Delivers complete HCI frames to the core.
> HCI EMU driver (hci_uart.o). Uses HCI Core interface to register/unregister devices.
> Provides virtual HCI devices functionality for user-space HCI emulators.
> L2CAP protocol module (l2cap.o). Features and interfaces:
>         L2CAP sockets:
>                 Supports all standard socket stuff: connect, bind, listen, accept, read, write, etc
>                 Seqpacket socket type for connection oriented channels
>                 Raw socket type for sending/receiving signalling messages
>         Simple routing between interface (HCI devices)
>         Multi threaded frame processing:
>                 Inherently multi threaded by HCI core
>         L2CAP features:
>                 Up to 64K L2CAP mtu (fragmentation / reassemble)
>                 Unlimited number of channels per connection
> Stack was designed for 2.4.x kernel (back port should possible thou).
> Testing was done on Pentium (from P/100 to PIII) and Sparc 64 machines using Digianswer and Ericsson UART and USB devices.
> SMP correctness was tested on Dual PPro 200 SMP machine. Interroped with Digianswer, Ericsson, Toshiba, Axis, IBM and other Bluetooth stacks.
> All modules are auto-loadable and loaded only on demand.
> 2. Utilities
> hcid            -  HCI daemon. Device initialization and monitoring.
> hciconfig       -  HCI device configuration. Something like ifconfig. Here is output example:
> hcidump -  Bluetooth frames analyzer. Something like tcpdump.
> l2ping          -  L2CAP ping utility.
> l2test          -  Various L2CAP tests. Different MTUs, PSMs, multiple channels, etc
> 3. Applications
> rfcommd -  Port of Axis RFCOMM code to L2CAP sockets. Non RFCOMM part is based on VTun.
>                    (will be released soon)
> vtund           -  Port of my VTun project to L2CAP sockets. Supports IP, Ethernet, PPP over L2CAP.
>                    (will be released soon)
> Some output examples from my SUN box:
> ultrablue:~>hciconfig
> hci0:   Type: UART
>          BD Address: 00:D0:B7:03:4B:3D ACL MTU: 672:10  SCO: MTU 0:0
>          RX bytes:69 acl:0 sco:0 events:8 errors:0
>          TX bytes:36 acl:0 sco:0 commands:7 errors:0
> hci1:   Type: UART
>          BD Address: 00:D0:B7:03:4B:3B ACL MTU: 672:10  SCO: MTU 0:0
>          RX bytes:69 acl:0 sco:0 events:7 errors:0
>          TX bytes:36 acl:0 sco:0 commands:7 errors:0
> ultrablue:~>l2ping 00:D0:B7:03:4B:3B
> Ping: 00:D0:B7:03:4B:3B from 00:D0:B7:03:4B:3D (data size 20) ...
> 20 bytes from 00:D0:B7:03:4B:3B id 200 time 39.28ms
> 20 bytes from 00:D0:B7:03:4B:3B id 201 time 50.10ms
> 20 bytes from 00:D0:B7:03:4B:3B id 202 time 40.11ms
> 20 bytes from 00:D0:B7:03:4B:3B id 203 time 50.11ms
> 20 bytes from 00:D0:B7:03:4B:3B id 204 time 50.17ms
> 20 bytes from 00:D0:B7:03:4B:3B id 205 time 50.11ms
> 20 bytes from 00:D0:B7:03:4B:3B id 206 time 50.11ms
> 20 bytes from 00:D0:B7:03:4B:3B id 207 time 50.29ms
> 8 sent, 8 received, 0% loss
> ------
> For those who are concerned about size :))
> [root@xxxxxxx.0]# lsmod
> Module                  Size  Used by
> l2cap                  17520   2  (autoclean)
> hci_uart                4656   2  (autoclean)
> hci                      22576   3  (autoclean) [l2cap hci_uart]
> --------
> And finally, announcement:
>       Qualcomm has released BlueZ - Bluetooth protocol stack for Linux under GPL license.
>       Project is hosted on http://bluez.sourceforge.net (web site, CVS, mailing list, etc).
> So, I think it's time to join forces. New stack design should solve lots of problems. Like unified
> hardware interface, hot-plugging, proper interface to lower layers, etc.
> Now user apps would look like normal socket applications without that ioctl black magic :).
> RFCOMM port took about 2-3 hours, HCI emulator and SDP should be no different.
> Your comments would be highly appreciated.

Ok. Wow. Looks pretty clean. Didn't see the RFCOMM source. Did you implement it (RFCOMM) in user space with a pty?


To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com