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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
