Hi An Chao, Isn't it possible to have a similar implementation that works for FLAT, Protected and Kernel modes?
This way the maintenance will be easier. Only small kernel-specific parts will remain there (as Raiden and Xiang proposed). Suggestion: instead of naming it libs/libbt/, it would be better to use libs/zblue to make it clear that it is a zblue port from Zephyr. Let's use libs/libbt only for NuttX-specific (native) code. And as I said, it is better to easily isolate the code that came from Zephyr's zblue. This way the user could select the Bluetooth stack they want without having code from the other stack attached to it. Also I suggest you to break your PR into smaller PRs; a single PR changing more than 660K LoC is very massive. BR, Alan On Fri, Oct 16, 2026 at 9:21 AM chao an <[email protected]> wrote: > Hi Alan, > > Thank you for the thoughtful perspective and for engaging in the > discussion. > > On security: we will maintain the Bluetooth stack ourselves and take > responsibility for tracking and fixing vulnerabilities. I'm also confident > that Xiaomi will contribute back on security issues given their ongoing > investment in this codebase. This isn't a blind import — it's code that has > active, committed maintainers behind it. > > Regarding the history with Greg: you're right that we discussed this years > ago. But there's an important distinction — that earlier proposal placed > the stack entirely in userspace. It did nothing to strengthen NuttX's > kernel-level Bluetooth support. That's precisely why I'm back now, > providing a kernel implementation this time around, which is what I > committed to back then. Feel free to search the mailing list archives — the > NuttX native Bluetooth stack will evolve from this baseline going forward. > > This implementation does not affect existing Bluetooth stacks in any way. > Users can still choose NimBLE, the current NuttX BLE stack, or any other > solution. This is an additional option, not a replacement. The goal is to > give NuttX users more choices, not fewer. > > One more update: I just spoke with Xiaoxiang and we've reached some common > ground. He's no longer opposed to the current stack implementation and > agrees that the focus should be on proper structuring. Here's the plan > going forward: > > 1. Unused shell code will be moved out of the stack and into apps/, > running entirely in userspace. > 2. Bluetooth profiles will be migrated to libs/libbt/, where we'll > provide two OS API backends: a POSIX API implementation (for > kernel/protected builds) and a NuttX kernel API implementation (for flat > mode). > 3. The L2CAP layer will remain in the NuttX kernel. > > This should address the architectural concerns while preserving the > performance path for flat-mode deployments. > > Alan C. Assis <[email protected]> 于2026年10月16日周五 18:40写道： > > > Hi An Chao, > > > > Thank you for trying to improve the NuttX Bluetooth support. And thank > you > > to bring this discussion here to let more people give their opinion. > > > > I think most of the concerns raised by Xiang and Raiden (Mateusz) are > > important and need to be addressed. > > > > As I said at GitHub PR I think a main concern here is using the same > > Bluetooth stack used on Zephyr, not because it is a bad stack (of course > it > > is not, it was developed by experts on Bluetooth area), but because we > are > > adding the same surface area of attack from Zephyr on NuttX. > > > > That means any security vulnerability affecting Zephyr BLE stack will > > affect NuttX. It remove the protection that a companies could obtain when > > using different RTOSs. > > > > Also, if my memory still serving me, I think Xiaomi team (you was there > at > > that time) already tried to submit their initial port of Zephyr BLE stack > > to NuttX about 4 or 5 years ago and Greg was against it. > > > > His suggestion was to improve our BLE stack, that in fact has the same > > origin of the Zephyr BLE stack (both came from a BLE stack from Intel > > released as BSD license at that time). > > > > I'm not against including the Zephyr BLE stack, but it should be > > selectable. Ideally the user should select if he/she wants to use NimBLE, > > Zephyr or NuttX native BLE stack. > > > > BR, > > > > Alan > > > > On Friday, October 16, 2026, chao an <[email protected]> wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
