I think there's a misunderstanding. Let me clarify the architecture once more, as this has been stated several times already in this thread:
1. L2CAP and below will live in the kernel. This is the same layering as the existing network stack — TCP/IP sits in the kernel, and that's not controversial. L2CAP is the BLE equivalent of the transport layer. It belongs there for the same reasons. 2. Higher-level profiles (GATT, GAP, etc.) will be moved to libc once the full stack integration is complete. They will use standard POSIX APIs and live in userspace, exactly as NuttX's architecture expects. 3. What you're seeing right now is Phase 1 only. This has been mentioned in the subject and in previous messages. It's an incremental merge — we're not dropping the entire BLE stack into the kernel and calling it done. The final architecture will respect NuttX's layering conventions: transport in the kernel, application-layer protocols in userspace/libc. This is fundamentally the same pattern NuttX already follows for IP networking. I'm not proposing anything that violates the project's architectural values. raiden00pl <[email protected]> 于2026年10月16日周五 14:56写道： > Your response has nothing to do with my reply to your comment about Nimble. > No one is claiming that the porting layer in Nimble is perfect, but it > certainly > doesn't use the kernel's private API. > > Good architecture and POSIX compliance are the core values of this project. > It has always been this way, and I hope it remains so. For this reason, > adding > anything to the kernel that sits above the L4–L5 layers of the OSI model is > a bad idea and I hope it never happens. > > > pt., 16 paź 2026 o 08:44 chao an <[email protected]> napisał(a): > > > Hi raiden00pl, > > > > Regarding your point about the NimBLE port using the POSIX API — yes, it > > uses POSIX, but there are real issues with the current implementation > that > > go beyond just kernel/protected mode support. > > 1. ble_npl_hw_enter_critical is not a real critical section > > > > Look at the NuttX port's implementation: > > > > > https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c > > > > static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; > > > > uint32_t ble_npl_hw_enter_critical(void) > > { > > pthread_mutex_lock(&s_mutex); > > return 0; > > } > > > > This is a mutex, not a critical section. It does not disable interrupts > or > > preemption — an ISR can still fire and corrupt data that the "critical > > section" was supposed to protect. On top of that, using a mutex opens the > > door to ABBA deadlocks when combined with any other lock held inside the > > critical region: > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ← > blocked > > by B > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A > > > > Compare this with the FreeRTOS port, which correctly uses > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling > > scheduling/preemption). The current NuttX port simply does not meet the > > semantic contract that the NimBLE stack expects from > > ble_npl_hw_enter_critical. > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...), > which > > involves a syscall and floating-point arithmetic on every call. In a BLE > > stack where timestamps and timing are on the hot path, this adds > measurable > > overhead compared to accessing the kernel tick counter directly. > > 3. Others are already using the kernel approach — and for good reason > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX > > uses kernel APIs directly, bypassing POSIX for the performance-critical > > paths: > > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel > > > > This isn't an academic exercise — it's a production choice. They > recognized > > that a BLE stack needs tight integration with the OS timer subsystem, > > direct access to critical section primitives, and efficient event > delivery, > > none of which POSIX provides well in this context. > > My question > > > > If other organizations are already using a more performant, > architecturally > > correct kernel-level integration for their BLE stacks on NuttX, why > should > > we be told that we must use the slower, less correct POSIX path? NuttX's > > POSIX compliance is valuable, but it shouldn't come at the cost of > shipping > > a BLE stack with a broken critical section primitive. There should be > room > > for both approaches, and the decision should be driven by technical > merit, > > not by treating POSIX as the only acceptable answer. > > > > Best regards, > > > > raiden00pl <[email protected]> 于2026年10月16日周五 14:06写道： > > > > > > 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. > > > > > > > > > > > > > > >
