Hi, thanks Xiao and Raiden for your technical opinions which I also share so I will not iterate them again.
I am against merging this pr in NuttX repo it should be splitted between nuttx and apps-repos and use POSIX implementation as much as possible. We are focused on standards and compatibility. Another concern is the license which does not match our ASF one and does not include any LICENSE file additions to clarify the compiance aspect Best regards Alin J On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <[email protected]> wrote: > On Fri, Oct 16, 2026 at 3:49 PM chao an <[email protected]> wrote: > > > So the real reason you've been objecting to my proposal is that your team > > has been working on something similar, correct? > > > > If you can give me a clear timeline for when your implementation will be > > submitted upstream, I'm happy to withdraw my PR and let your code serve > as > > the baseline. I'm not here to fight over ownership of the Bluetooth > stack. > > My only motivation is that NuttX's lack of a capable Bluetooth stack is > > driving every developer toward Zephyr — and as a PMC member, I think you > > should be asking yourselves why this gap has remained unfilled for so > long. > > > > > I object to landing the whole bluetooth stack into kernel space directly > either yours and ours . > This is the same feeling from raiden00pl too, let's see other people's > opinions here. > But it's fine for me to host the whole code in nuttx-apps.git and refactor > components to kernel > space step by step. > > > > As for the current PR, I'll remove the shell components from the stack > and > > move them into apps/ where they belong. The base profiles (A2DP, BLE) > will > > stay in libc — > > > The architecture is wrong to host any bluetooth profile in libc. > > in flat build mode this gives a significant performance > > boost to the overall stack, which is the primary deployment model for > most > > NuttX devices. > > > > > Performance should remain the same whether the base profile is hosted in > libc or apps, > could you point out any technical reason which impacts the performance in > the flat mode? > > > > A few additional data points regarding our timeline: our product is > > scheduled for release in December, and Bluetooth SIG certification is > > already in progress — we expect to receive it around November. If the > > baseline were to switch to your team's stack with its different > > architecture, that certification cycle would need to be repeated, which > is > > not trivial given the time and cost involved. > > > > Xiang Xiao <[email protected]> 于2026年10月16日周五 15:08写道： > > > > > 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 > > > > > >
