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

[bluetooth-dev] Stack design and some anoucements



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.
Thanks
Max

Maksim Krasnyanskiy		
Senior Kernel Engineer
Qualcomm Incorporated

maxk@xxxxxxx.com
(408) 557-1092

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