Re: Bluetooth and HAL (Was Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?)

[Marcel Holtmann <marcel holtmann org>]

Hi David,

> > So the missing pieces are to link other Bluetooth kernel services like
> > RFCOMM, HID, BNEP or CAPI with the Bluetooth adapter. I haven't come up
> > the best approach to do this right. The obvious problem is if you have
> > a /dev/rfcomm0 device for example. How do you tell which Bluetooth
> > adapter it is assigned to. And of course RFCOMM is capable of picking
> > any available adapter if you give it the wildcard source address.
> 
> What's wrong with having the actual Bluetooth devices (not the adapter)
> live in sysfs below the adapter
> 
>  http://people.freedesktop.org/~david/bt.txt
> 
> as described in that link?

I spent a lot time argumenting about this with myself and I haven't come
to final conclusion yet. In general you have to create a new device for
every device you discover or connect to. Which is actually not a bad
idea after all and I saw that the UWB subsystem is actually doing such
thing everytime they get a beacon.

If we gonna go into this direction then it needs massive changes in the
Bluetooth core itself. At the moment we only have adapters presented
through hci_dev and connection (ACL and SCO) presented through hci_conn.
And the assumption that you only have one ACL link per connection might
not be longer true in the future. The inclusion of UWB as transport for
Bluetooth will change some things.

However it might be worth to define an empty bt_dev structure and
actually link it with inquiry results and hci_conn to create a bus alike
device tree. This also means we need to present hci_dev as bt_host,
because otherwise we can't differentiate between devices seen from two
different adapters.

I am open for suggestions here. It is not easy to tell if Bluetooth
better fits into the class device model or be better a simple device on
a bus.

Regards

Marcel