Hi Alan, Thanks for the comments and suggestions.
For the first stage, I would prefer to keep the Bluetooth host stack supported only in FLAT mode. Supporting Protected and Kernel modes requires a much deeper rework of the stack and its interfaces, especially around the boundary between kernel space and user space. I do not think it is a good idea to introduce such large architectural changes in this first step. Our current plan is to complete Protected/Kernel mode support in a second stage, after the basic stack integration is reviewed and stabilized. This should make the initial review and integration much more manageable. Regarding the library name, I still prefer to use libs/libbt. Although the current code is based on Zephyr's zblue, the goal is to maintain it as an independent NuttX Bluetooth host stack going forward, rather than keeping it as a direct Zephyr fork forever. In that sense, I think libbt is a better long-term name. Also, the current NuttX Bluetooth profiles are not implemented in the kernel, and we do not plan to move the native NuttX Bluetooth stack profiles into the kernel either. Once Protected/Kernel mode support is added for this stack in the future, this implementation is expected to replace the previous approach. For this reason, I think keeping the stack under libbt is still more appropriate. About splitting the PR: this PR is already the result of squashing more than one hundred commits. Most of those commits are compatibility-layer adjustments, coding style cleanup, and mechanical changes needed to make the stack build in NuttX. Asking reviewers to review each of those commits separately would probably cost everyone more time. Splitting the full Bluetooth stack by profile is also not very practical at the moment, because there are no dedicated maintainers for each individual Bluetooth profile area in NuttX yet. Therefore, I think the current form is probably the most reasonable way to review and integrate the stack as a whole. One more update: I have removed all shell-related code from https://github.com/apache/nuttx/pull/20686. The plan is to move those shell commands to apps later. With this change, the current Bluetooth stack no longer contains any user-space shell code, so I think this is now a better point for review. Best regards, Alan C. Assis <[email protected]> 于2026年10月16日周五 21:40写道： > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
