On Fri, Oct 16, 2026 at 11:25 AM chao an <[email protected]> wrote:
> Hi all, > > I would like to summarize the background, technical motivation, and > proposed evolution plan for PR #20686, which introduces a Zephyr-based > Bluetooth host stack under net/bt. > > https://github.com/apache/nuttx/pull/20686 > > First of all, I fully understand the concerns raised in the discussion. > Adding a new Bluetooth stack is a significant architectural change, and it > is reasonable for the community to ask whether we should instead continue > improving the existing NuttX Bluetooth implementation. I would like to > explain why we believe introducing the new stack incrementally is the more > practical path, while still keeping the long-term NuttX architecture clean > and maintainable. > ------------------------------ > 1. Why not only enhance the existing NuttX Bluetooth stack? > > The existing NuttX Bluetooth implementation is mainly focused on BLE > functionality. However, modern Bluetooth support is no longer limited to > basic BLE. A complete Bluetooth host stack now commonly includes: > > - BLE GAP/GATT/ATT/SMP > - Classic Bluetooth profiles > - A2DP > - AVRCP > - HFP/HSP > - HID > - LE Mesh > - LE Audio > - Additional profile-level interoperability logic > > But most of these profiles should belong to the userspace, please split the related code to nuttx-apps.git, instead nuttx/. especially, the code related shell spread in the whole code base: https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/ https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell it's definitely wrong to put the shell code inside kernel space. > The Zephyr Bluetooth stack already provides a broad and actively maintained > implementation across many of these areas. Rebuilding equivalent > functionality directly on top of the current NuttX Bluetooth stack would > require a very large multi-year effort, including not only protocol > implementation but also interoperability testing with real phones, > headsets, speakers, cars, and other commercial devices. > > Therefore, our goal is not to discard NuttX's existing work lightly, but to > provide a practical path to make NuttX capable of supporting a much wider > Bluetooth feature set in a reasonable time frame. > ------------------------------ > 2. Why place the stack in nuttx instead of nuttx-apps? > > Another important discussion point is whether the new Bluetooth stack > should live in nuttx-apps, similar to how NimBLE is currently integrated. > > Our concern is that a host stack is not just an application-level > component. It interacts closely with: > > - HCI transport > - L2CAP channels > - Socket or device interfaces > - Memory pools > - Timers and work queues > - Security and pairing state > - Profile registration > - Controller event dispatch > - Future kernel/user boundary mechanisms > > Putting the core host stack in nuttx-apps would either require exposing > many internal kernel interfaces or would force the application-side stack > to depend on non-public NuttX internals. > > We already have a similar problem with the current NimBLE integration. The > NimBLE port in nuttx-apps directly depends on many NuttX kernel/internal > APIs. As a result, it is difficult to support protected/kernel builds > cleanly, and it is also hard to keep the port synchronized with upstream > NimBLE over time. > > These are kernel public API, the only problem is that they are called by userspace. > For this reason, we believe the Bluetooth host core belongs in the NuttX > tree. User-facing profiles, tools, shell commands, or demo applications can > still live outside the core as appropriate, but the transport-facing host > stack should have a well-defined place inside NuttX. > > There is also a performance consideration. In flat build mode, the > Bluetooth host stack can run directly on the kernel side without additional > syscall or user/kernel boundary overhead. This is especially important for > IoT chips with relatively low CPU frequency, where Bluetooth data path and > profile handling overhead can have a visible impact on throughput, latency, > and power consumption. > > At the same time, this does not mean that the final architecture must > remain flat-build-only. A compatible evolution path is to keep the > performance-sensitive transport and host core on the kernel side, while > gradually moving suitable Bluetooth profile implementations or > profile-facing helper layers into libc-visible build paths. This allows > protected and kernel builds to use proper public interfaces, while still > preserving good performance for flat build and low-end IoT platforms. > > In other words, placing the stack in nuttx gives us a cleaner long-term > architecture: > > - Flat build can get the best performance with minimum overhead. > - Protected/kernel build can be supported later through proper public > interfaces. > - Profile code can be migrated into libc-compatible paths where > appropriate. > - Userspace does not need to directly depend on private kernel symbols. > - The design avoids repeating the long-term maintainability issue seen > in some existing userspace Bluetooth integrations. > > But Zephyr bluetooth stack is implemented as a monolithic block like NimBLE. Your current porting just include: 1. Switch Zephyr API to NuttX kernel API 2. Format the code base to follow The NuttX coding style No any change related to the kernel/user space separation, so it's better to contain in nuttx-apps.git in the current stage. I would suggest you put the initial code inside nuttx-apps and move the part which belongs to the kernel step by step, so the community can review the change more carefully.
