[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] Stack design and some anoucements
>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_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.
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.
Senior Kernel Engineer
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org