Hi, On Wed, Aug 11, 2010, Pavan Savoy wrote: > When you say raw HCI access do you mean doing the > socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI) and bind/ioctl, writev+poll/read > lacks few things ? > but all of these are in lib/hci isn't it ? Yes, that's the type of socket that I meant. Direct access to the HCI messages would largely go away from the userspace side. Those libbluetooth functions you're referring to are just convenience wrappers for sending HCI commands through raw HCI sockets. > So even if it was netlink only something like hci_open_dev() would > have changed to socket(PF_NETLINK, SOCK_RAW, BT_NETLINK ); or > something right ? I'm not really familiar enough with netlink to comment on this. Marcel (whose idea it originally was) would have to comment. > any pointers out there ? references for such things ? > I am just curious, don;t want anything specific ... Right now, not really. The only stack internal messages there are at the moment are things like HCI_DEV_REG, HCI_DEV_UNREG, HCI_DEV_UP and HCI_DEV_DOWN and they only go one way (kernel->userspace). This category of messages will grow in the future and it'll be possible to send them both ways. Some HCI messages for which it's already clear now that there will be a benefit from a higher level abstraction on the userspace side are things like name resolving and pairing related requests. Also, if I understood correctly from Marcel, removing userspace processing of HCI events will result in a considreable reduction of context switches since there wont anymore be a promiscuous userspace-side socket that needs to handle/filter all HCI data (Marcel, please correct me if this is inaccurate or wrong). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
