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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
