On Fri, Oct 16, 2026 at 12:53 PM chao an <[email protected]> wrote:
> No, I do not agree that the current port is only a Zephyr API replacement > and > NuttX coding-style reformatting. > > > > This code base has already fixed part of the issues that still exist in the > > Zephyr community implementation. In addition, we still have pending > features and > fixes that have not been submitted yet. Since some of those changes were > made by > other developers, I cannot submit their work by myself without proper > permission > and attribution. > > > https://github.com/zephyrproject-rtos/zephyr/pull/122348 > > > I have already stated in the email why I do not recommend putting the > initial > Bluetooth host stack into nuttx-apps. Architecturally, placing it in apps > would > cause significant performance degradation compared with the Zephyr design. > The > Bluetooth host stack is tightly coupled with kernel primitives, buffer > > management, work queues, timing, and HCI/driver paths. Moving it entirely > to > apps would change that integration model and make the architecture worse > from > the beginning. > > I don't see any performance degradation by moving your whole patch to nuttx-apps.git. You can call kernel api directly and the bluetooth stack still can only run in the flat mode. And then you can do the planned work by moving the suitable component to kernel spaces. > > Therefore, please read my previous email more carefully. The concern here > is not > only the initial review size, but also the long-term architecture and > runtime > performance of the Bluetooth stack in NuttX. > > BRs, > > Xiang Xiao <[email protected]> 于2026年10月16日周五 12:44写道： > > > 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. > > >
