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. > > Right. It's also interesting how things like Wireless USB is going to > fit in here. > > For me it comes down to this: since you seem to provide kernel drivers > for e.g. input and ALSA functionality from Bluetooth devices don't you > think it would be nice with the device-> symlink so it's easy to figure > out the relationship between class devices and bus devices? I mean, the > kernel _already_ knows about the remote Bluetooth devices, all I'm > asking for is to put them in sysfs. > > My crappy patch here > > http://people.freedesktop.org/~david/bt.txt > http://people.freedesktop.org/~david/davidz-bluetooth.patch > > did exactly that. I really don't know how we'd integrate Bluetooth input > and audio devices if HAL doesn't know about this. > > Going forward it would be super useful to also have e.g. a 'pair' file > you could read from ("is the device paired?") and write to ("attempt to > pair a device"), e.g. have parts of the Bluetooth control functionality > through sysfs. I don't know the details and if you say there are good > reasons to go through a user space Bluez D-BUS interface instead of just > sysfs that's fine with me. But I thought I'd raise this anyway :-)
I didn't know that the driver model can now link class devices to actual real devices. However it can do that and so I converted all Bluetooth host controller into real devices with a pseudo platform device as parent for virtual and serial devices. The patch for this has been tested since a week and I sent it to David Miller for inclusion. I also tried to represent every remote device as child, but this failed so far. It triggers a BUG_ON() in the mutex slowpath and I need more time to fully understand it. A possible solution is schedule_work() like David did, but I have to check some possible race conditions first. So this email is to inform you that I am on my way to fully integrate local and remote Bluetooth devices into the driver model. Regards Marcel _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
