Hi Anchao, Yes, I think having a complete BLE stack like zblue is a good idea.
But we need to find a middle ground for correct integration. Let's do this: add zblue to libs/zglue and maintain a proper separation to allow room for the existing BLE stack on NuttX to evolve. Just assuming that not updating/synchroning zblue with Zephyr's zblue will be enough for them to become different entities seems incorrect. The amount of code is very large, so even after decades they will share enough of their "DNA" that a virus will be able to infect both. Do you think it is possible to modify your PR to let both stacks (+ NimBLE userspace stack) work on NuttX without one interfering on the other? BR, Alan On Thu, Oct 22, 2026 at 12:20 AM chao an <[email protected]> wrote: > Hi Alan, > > > > Thank you for the detailed analysis. > > > > I understand your concern. The current code structure is indeed still very > > close to Zephyr's Bluetooth stack, and the compatibility layer is currently > > quite thin. However, from the long-term technical direction, our intention > is > not to keep doing long-term synchronization with Zephyr. Instead, we plan > to > quickly feed back the related issues and improvements to the NuttX > community > during the integration and evolution process. > > > > Regarding the naming concern, I think it is reasonable to call it zblue > > temporarily, since the current implementation is still largely based on > > Zephyr's Bluetooth stack. If the stack evolves later with a new code > structure > and clearer NuttX-specific architecture, we can further evaluate whether a > > different name would be more appropriate at that time. > > > > Does that sound reasonable to you? > > > > BR, > > > Alan C. Assis <[email protected]> 于2026年10月22日周四 03:41写道： > > > Hi Anchao, > > > > I used Claude to help compare the code and here are the reasons to call > it > > zblue instead of libs/bt: > > > > Almost all of this PR is Zephyr's Bluetooth stack > > ("zblue"), reformatted to NuttX style. The part that doesn't come from > > Zephyr is > > a thin compatibility layer that makes the Zephyr kernel calls work on > > NuttX. > > > > I pulled all 539 new files (400,450 lines) and compared them against > > several > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it matches > > better > > than Zephyr's current main branch. So the PR looks like a snapshot of > zblue > > from the last few weeks. > > > > Results > > > > Function by function (7,716 functions): > > > > Class: Identical > > Functions: 5,411 (70%) > > Lines: 140,189 > > Meaning: Exactly the same code as Zephyr. Only indentation and braces > > differ. > > ──────────────────────────────────────── > > Class: Renames only > > Functions: 1,515 (20%) > > Lines: 60,863 > > Meaning: The only changes are API renames that recur across the whole > PR: > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1), > sys_slist_*→list_*, > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read > > ──────────────────────────────────────── > > Class: Modified > > Functions: 584 (8%) > > Lines: 33,693 > > Meaning: Clearly the Zephyr function, plus some edits specific to that > > function > > ──────────────────────────────────────── > > Class: Not from Zephyr > > Functions: 206 (3%) > > Lines: 2,734 > > Meaning: NuttX glue code > > > > Whole files, including headers: > > - On average, 96.9% of each file's code also appears in its Zephyr > > counterpart. > > - 434 of the 539 files are ≥90% the same as Zephyr; together they hold > > 375k of > > the 400k lines. > > - 75% of the comment text, including the Doxygen docs, is word-for-word > > Zephyr. > > > > What's actually new: > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c, mem_slab.c, > > fs.c, > > sections/defines.c, hci_driver.c), which provides k_work, k_queue and > > similar > > Zephyr calls on top of NuttX. > > - Part of mm/net_buf. > > - bt_nus_auto_start_bt.c, which has been heavily extended. > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig. > > > > > > So, only 3% of the code is new (this includes the code in sim:bt that > must > > be new). > > > > So, reusing the zblue from Zephyr and calling it something else isn't > > right; it's like the zbus that Jorge brought from Zephyr, where calling > it > > NXBus doesn't seem appropriate. > > > > Besides that, as I said before using ZBlue as our official BT Stack will > > significantly increase the shared code between NuttX and Zephyr, which > > could be dangerous. > > > > As I said, I not against adding ZBlue to NuttX, but at least make it > clear > > that it is ZBlue and should be an alternative stack (like NimBLE) not the > > official NuttX BLE Stack. > > > > BR, > > > > Alan > > > > On Mon, Oct 19, 2026 at 12:34 AM chao an <[email protected]> wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
