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

[Maksim Krasnyanskiy <maxk@xxxxxxx.com>]

Greg,

>The one current advantage of using a tty device as a low level driver
>is that the current usb bluetooth driver works with about 4 different
>Linux Bluetooth stacks (yes there are more out there.)  
Agree. However my goal was to design and develop general hardware independent 
interface for HCI core. People are working on HCI over PCI and stuff like that, so 
emulating TTY functionality would completely inefficient.
Current interface is clean and simple. 

Stack uses SKBs on all layers. Somebody in the list said that they are no different from kmem_alloc which is _not_ true.
SKBs are different because they are SLABified which means that there is a cache for SKB heads and allocations are 
optimized. Also SKBs provide lots of nice optimized functions and queues, so reinventing the wheel is not necessary :) 

HCI core:
         hci_register_dev                -       Register HCI device.
         hci_unregister_dev      -       Unregister HCI device.

         Whenever HCI device is registered HCI core sends stack specific event to the raw sockets notifying applications that 
         that device was added or deleted which for example allows hcid to initialize device and bring it up (hot-plug). Also HCI
         core internally notifies all registered protocols (L2CAP) so the can initialize or cleanup.

         hci_recv_frame          -       Receive and process complete HCI frame.
         HCI drivers are responsible for providing complete and already classified frames. They feed HCI core skbs with 
         complete frame in skb->data and skb->pkt_type set to the proper HCI packet type.
         
HCI drivers:
         open            -       Open, init and start device. 
         flush           -       Flush buffers.
         close           -       Close, uninit device.

         send_frame      -       Send complete frame.
         HCI core prepares complete HCI frames in skb->data and sets skb->pkt_type. 

As you see HCI part of the driver is very very simple. For those who interested in code example look at the hci_emu 
implementation. It's a combination of char device and hci device. When ever user app opens /dev/hciemu driver registers 
new HCI device with Core and then relays data between hci dev <--> file descriptor.
So you can write HCI emulation app that will read/write from/to char device and do HCI emulation.
Idea is based on my TUN/TAP driver which does the same thing for Net devices.    

>I'm all for increased speed, and code sharing, but because of this
>compatibility, I can't justify removing the current bluetooth.c driver
>from the usb driver tree.
Let's keep them both :).

>I have a few minor usb driver suggestions that I'll send on later based
>on skimming hci_usb.c.
Great. Would be happy to discuss them.

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