> 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.
Is this an AI analysis or something? Because it’s definitely not true: Nimble port uses the POSIX API. The only issue with kernel mode is that SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx limitation, not a port architecture issue. I agree that synchronizing with an external repository is a challenge. However, a plus side is that we aren't the ones maintaining the code that must comply with the BLE standard. I also consider placing the entire BLE stack within the kernel to be a bad idea. Even if performance isn't ideal, it’s the price one pays for a sound architecture. NuttX has always focused on addressing architectural challenges (POSIX compliance) rather than striving to be the best in terms of performance. pt., 16 paź 2026 o 06:52 chao an <[email protected]> napisał(a): > 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. > > > > 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. > > >
