[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
> UP RUNNING NORMAL PSCAN ISCAN
> 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
> UP RUNNING NORMAL PSCAN ISCAN
> 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?
--gmcnutt
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com