xiaoxiang781216 edited a comment on pull request #2302: URL: https://github.com/apache/incubator-nuttx/pull/2302#issuecomment-748122021
> > 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. ---------------------------------------------------------------- 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: us...@infra.apache.org
