On Fri, Oct 16, 2026 at 3:06 PM chao an <[email protected]> wrote:
> 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. > I don't agree with putting the bluetooth profile into libc, it must be moved to nuttx-apps.git or separated git. > 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. > > Based on the current implementation, what I would prefer is to keep the porting in nuttx-apps.git and move the transport/driver layer to the kernel. > 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. > > > > > > > > > > > > > > > > > > > > >
