Any reason behind making hciops a plugin and bluetoothd making use of
that plugin, wasn't everything straight up in hcid before ?
Thanks in advance.
Marcel, Johan,
On Thu, Aug 12, 2010 at 5:13 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Johan,
>
>> > 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.
Yes, this explains why hciops is a a plugin now, thanks...
>> 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).
>
> this is correct. We will not require userspace to do HCI event
> processing and filtering anymore. It will be a dedicated side channel.
Side channel ? But there would still be some way to bring out events
onto user-space right ?
As in application which do and ONLY do HCI-VS commands, and are
interested in HCI-VS events...
> Regards
>
> Marcel
>
>
>
Hi Johan,
> > 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).
this is correct. We will not require userspace to do HCI event
processing and filtering anymore. It will be a dedicated side channel.
Regards
Marcel
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
On Tue, Aug 10, 2010 at 9:16 PM, Johan Hedberg <[email protected]> wrote:
> Hi,
>
> On Tue, Aug 10, 2010, Pavan Savoy wrote:
>> Any reason behind making hciops a plugin and bluetoothd making use of
>> that plugin, wasn't everything straight up in hcid before ?
>
> We're planning on redoing the kernel-userspace interface and in the long
> run the traditional raw HCI access wont exist anymore in userspace. In
> order to accommodate both old and new kernels in a clean way the
> interface towards the kernel needs to be easily interchangable, which is
> what hciops is trying to do (it's just a first step in that direction
> though). One of the drivers for this change is the need to have the
> security logic in one place instead of it being split between kernel and
> userspace (this has caused all sorts of trouble with SSP for us).
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 ?
> Originally the plan for the new kernel interface was netlink but now the
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 ?
> idea is to simply extend the stack internal messages of raw HCI sockets
> with a more complete two-way protocol between the kernel and userspace.
> You should (hopefully) be seeing more patches for this still during this
> year.
any pointers out there ? references for such things ?
I am just curious, don;t want anything specific ...
> Johan
>
Hi,
On Tue, Aug 10, 2010, Pavan Savoy wrote:
> Any reason behind making hciops a plugin and bluetoothd making use of
> that plugin, wasn't everything straight up in hcid before ?
We're planning on redoing the kernel-userspace interface and in the long
run the traditional raw HCI access wont exist anymore in userspace. In
order to accommodate both old and new kernels in a clean way the
interface towards the kernel needs to be easily interchangable, which is
what hciops is trying to do (it's just a first step in that direction
though). One of the drivers for this change is the need to have the
security logic in one place instead of it being split between kernel and
userspace (this has caused all sorts of trouble with SSP for us).
Originally the plan for the new kernel interface was netlink but now the
idea is to simply extend the stack internal messages of raw HCI sockets
with a more complete two-way protocol between the kernel and userspace.
You should (hopefully) be seeing more patches for this still during this
year.
Johan