Hi, Tomek, Thanks for the thoughtful input and the FreeBSD references — those are very relevant to where we're heading.
Just to set the context: NuttX's current Bluetooth stack only supports BLE. Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing. This is exactly why we want to bring a more complete Bluetooth stack to NuttX — to catch up with what mainstream RTOS communities already offer. I actually agree with the FreeBSD/Apple architecture you referenced. Our end-state plan is similar: the L2CAP and HCI layers will live in the kernel, and a bluetoothd-style daemon will be implemented in libc, managing profiles and higher-level protocols. This gives us a clean separation — transport in the kernel, policy and profiles in userspace — much like how FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1 of getting there incrementally. Tomek CEDRO <[email protected]> 于2026年10月16日周五 17:07写道： > Thank you An Chao for this proposition, work, and discussion :-) > > For sure it would be nice to have a BT stack with more features! The > BT has known issue of having different implementations of the stack on > different RTOS / OS / platforms, which is a known issue, and kinda > mess because there is no common standard / approach / implementation, > unfortunately around something that is supposed to be based on a > common standard. > > Having common BT stack with other popular RTOS may make portability > easier and developers move to NuttX in some cases. > > I understand that we are talking about this solution? > > > https://docs.zephyrproject.org/latest/services/connectivity/bluetooth/index.html > > In a perfect situation we would want to have modular implementation in > nuttx-apps just like nimble. This is pointed out by Xiang, Raiden, and > Alin already. But I understand some things may be hard to implement > that way. I will follow the consensus here when ready, I have no > strong opinion here, except any BT stack I touched before was a mess > and I hope we can work out at least something decent :-P > > A bit offtopic but for kernel build we can take a look at quite old > Bluetooth implementation on FreeBSD, where radio is provided by ng_ubt > (lower half in out case), then upper half uses standard HCI. Maybe > something like this is possible in NuttX? > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3 > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4 > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl > > Here is a quick overview article on the Bluetooth implementation in > FreeBSD and Apple: > > https://pkgdemon.github.io/freebsd-bluetooth-management.html > > Again it will be very nice to have fully featured BT stack in NuttX > and I hope we can sort out the best possible porting implementation > :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <[email protected]> wrote: > > > > 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 > > > > > > > > > > > > >
