with flow control being applied. It is simpler and no more problematic to
accept the data and drop it if we hit a resource limit than to expect the
Bluetooth device to do anything about it (which it won't).
and the back end Bluetooth device driver. The device driver now
allocates a suitable buffer on behalf of the bthci driver, and bthci
fills the buffer before despatch.
This saves an ugly temporary allocation (in bthci) and memory copy (in
the USB driver) per write, and also works better with the
sockets-based interface I'm experimenting with.
actually functional driver. It provides a local HCI interface to the
HCI-over-USB interface on standards-compliant Bluetooth USB devices.
Currently this device can be attached to the bthci driver for direct user-land
access to the device.
itojun