Hi raiden00pl, Because the protocol stack itself hasn't undergone structural changes. What we've done so far is essentially kernel API replacement and code style adjustments — adapting the Zephyr stack to NuttX's kernel interfaces. The basic profiles (A2DP, BLE) are functional and working correctly at this stage.
Keeping this on master has a practical purpose: it lowers the barrier for other companies to see the work, test it, and contribute. This is exactly the model that works in the Zephyr ecosystem — NXP, Nordic, Xiaomi, and others all co-maintain the Bluetooth subsystem on the main branch. If we isolate this on a separate branch, two things happen: 1. Nobody guarantees long-term maintenance. A side branch inevitably falls behind as master moves forward, and the burden of rebasing and keeping it alive falls on whoever initially pushed it. That's not sustainable. 2. Companies and individual developers lose visibility. They won't track a side branch for information sync, won't test it against their hardware, and won't contribute back. The work becomes invisible and eventually bitrots. The goal here is to build a collaborative maintenance community around this code, not a throwaway prototype. That only works if the code lives where everyone can see it — on master. raiden00pl <[email protected]> 于2026年10月16日周五 15:13写道： > On another note, if this is a work-in-progress (WIP), why not create a > separate > branch in the upstream repository where this stack could be developed, and > then > merge it to master once it reaches a more mature stage? > This would keep the work public without adding unfinished code to the > master branch. > I recall that this approach was used previously for some of the > larger-scale, not finished changes. > > pt., 16 paź 2026 o 09:07 Xiang Xiao <[email protected]> > napisał(a): > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <[email protected]> wrote: > > > > > 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. > > > > > > > > I don't object to moving the key bluetooth stack to kernel space like how > > the current bluetooth stack is done, > > what I object to is that the current state of > > https://github.com/apache/nuttx/pull/20686 is far to move entirely > > into kernel space. > > If I low my quality bar, I have requested my teammate to upstream our > > implementation: > > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel > > since much work needs to be done before it can achieve the quality > > upstream. > > BTW, many zephyr class BT features are developed by my team and upstream > to > > Zeprhy community. > > If considering the quality, our version is much better since: > > > > 1. Product on smart speaker last year > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06 > > 3. Product on wear device by end of this year > > >
