Also, if you’re talking about performance, it would be appropriate to back that up with some real data.
>From your PR: > with CPU frequencies below 100 MHz — this copying becomes very costly. For example, with SPP bandwidth at 200 MB/s, this alone can consume more than 15% CPU load. This is total nonsense. SPP can't achieve 200 MB/s, it is impossible ! Sorry, but your claims regarding Nimble were simply false, furthermore, the example you provided abot SSP is also nonsense. I don’t like that. pt., 16 paź 2026 o 08:55 raiden00pl <[email protected]> napisał(a): > 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. >> > > > >> > > >> > >> >
