nuttx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on pull request #2302: bluetooth: fix outgoing buffer freeing
Date Fri, 18 Dec 2020 14:47:19 GMT

xiaoxiang781216 edited a comment on pull request #2302:

   > > HCI RAW socket is selected by WIRELESS_BLUETOOTH_HOST, but the right implementation
should enable RAW mode per socket instance. If we look at how Linux bluetooth stack work,
the RAW bluesocket don't require us to remove bluetooth stack and recompile kernel, so the
RAW bluetooth socket and NuttX native bluetooth stack isn't mutually exclusive.
   > That is indeed another option, to support this per-socket. I personally don't think
that makes much sense in an embedded system were you will have one BLE stack (why would you
want to support RAW sockets to be used by an external stack and still have NuttX stack enabled?).
   > In other words, I don't oppose to doing that but I would maintain the option to disable
NuttX stack as it would otherwise be wasteful when an external stack is used.
   Yes, your concern is right, but from API compability perspective, it's better to decouple
RAW socket from disabling NuttX stack:
   1. User can use RAW socket regardless whether NuttX bluetooth stack enable or disable
   2. Support WIRELESS_BLUETOOTH_HOST option too
   > Anyway, this goes beyond the fix that is needed for the problem mentioned in this
PR, which is relatively simpler compared to that. I think we need to break down this as follows:
   > * fix the buffer freeing and restore NuttX current BLE stack functionality (@btashton
are you able to look into this as you mentioned?)
   Agree, we need make NuttX BLE stack work again. With or without WIRELESS_BLUETOOTH_HOST.
   > * have a discussion on what do we want to do with NuttX BLE stack to properly support
it using sockets (modify it? replace it?)
   > * continue improving BTPROTO_* socket handling in NuttX (Brennan had further plans
with this)
   > Meanwhile, having nimBLE supported at least gives us a mature stack exposed via sockets
in NuttX.
   I wouldn't suggest to modify all monolithic bluetooth stack too much(remove L2CAP and HCI
layer). The possible solution is that we select one profile only bluetooth stack(bluez?) directly
or modify one monolithic bluetooth stack(nimBLE or zerphyr?) heavily to utilize the full feature
bluetooth socket.
   All rest monolithic bluetooth stack can use either TPROTO_* raw socket or /dev/tty* interface
to access the BT/BLE controller. It doesn't have too much difference from the archecture perspective
for these two approach since NuttX native kernel bluetooth stack(L2CAP and HCI) get bypass

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:

View raw message