Hi Alan, Tomek,
Thank you! And thanks to everyone who provided suggestions, review comments, and testing help on this patch. The feedback was very helpful for cleaning up the layout, license handling, Kconfig organization, and build integration before merge. I really appreciate all the guidance and support from the community. BR, Tomek CEDRO <[email protected]> 于2026年10月23日周五 06:27写道： > Thank you Anchao and Alan :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Thu, Oct 22, 2026 at 1:46 PM Alan C. Assis <[email protected]> wrote: > > > > Great, thank you very much Anchao! > > > > On Thu, Oct 22, 2026 at 10:36 AM chao an <[email protected]> wrote: > > > > > Hi Alan, > > > > > > > > > > > > Thanks for the suggestion and for offering to help with testing! > > > > > > > > > > > > I agree with your point. It is better to avoid introducing net/bt as an > > > > > > intermediate layout if we already know it will be moved later, since > that > > > > > > would create unnecessary churn and could become a breaking change after > > > > > > merge. > > > > > > > > > > > > I have updated the patch accordingly: > > > > > > > > > > > > - Moved the Bluetooth host stack build integration out of net/ > > > > > > - Kept the implementation under libs/zblue > > > > > > - Added libs/zblue as a standalone NuttX library, similar to other > libs/* > > > > > > components > > > > > > - Moved the Kconfig entry under the top-level Wireless Support menu > > > > > > - Registered libzblue through the standard Make library target flow > > > > > > - Reworked the Make.defs paths to use TOPDIR-based paths instead of > > > relative > > > ../libs/zblue paths > > > > > > > > > > > > I also re-tested the integration with the sim:bt configuration, and the > > > native > > > Make build passes. I re-ran nxstyle and codespell as well, and both are > > > clean. > > > > > > > > > For the Kconfig selection, I agree that more explicit options will > make it > > > > > > easier for users to enable only the parts they need. I will continue > > > refining > > > that so the stack is not exposed as one overly broad switch. > > > > > > > > > > > > Thanks again for the review and for working on the BT side too. Any > > > additional > > > testing from your side would be very welcome. > > > > > > > > > > > > BR, > > > > > > > > > Alan C. Assis <[email protected]> 于2026年10月22日周四 20:28写道： > > > > > > > Hi Anchao, > > > > > > > > Sounds good! > > > > > > > > Yes, I suggest going with more explicitly selection in the Kconfig so > > > users > > > > can select what they want more easily. > > > > > > > > Regarding "net/bt," there is not a more permanent solution than a > > > temporary > > > > one. This is a reason to avoid it. > > > > > > > > I understand that you tested the integration this way and agreed to > > > change > > > > it to libs/zblue later, but I strongly recommend making that change > > > before > > > > merging. > > > > > > > > Adding something that will probably change will result in a "breaking > > > > change" later, which we are trying to avoid on NuttX. > > > > > > > > So the best moment to change it is before it gets merged. If you need > > > help > > > > testing, I can assist here. I'm already working on BT (first fixing > small > > > > issues). > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Thu, Oct 22, 2026 at 8:55 AM chao an <[email protected]> wrote: > > > > > > > > > Hi Alan, > > > > > > > > > > Yes, I agree that we need to find a middle ground and make sure the > > > > > integration does not block the existing Bluetooth solutions in > NuttX. > > > > > > > > > > From the current implementation, I don't think this zblue-based > stack > > > > > conflicts with NimBLE or with the existing in-tree BLE stack. They > can > > > be > > > > > selected independently through Kconfig. For example: > > > > > > > > > > - CONFIG_BT Enables the new zblue-based host stack currently > added > > > by > > > > > this PR. > > > > > - CONFIG_WIRELESS_BLUETOOTH > > > > > - CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE > stack > > > > > under wireless/bluetooth. > > > > > - CONFIG_NIMBLE Enables the userspace NimBLE stack when that > stack > > > is > > > > > used from apps. > > > > > > > > > > The lower-level Bluetooth controller / transport drivers are also > > > > separate, > > > > > for example: > > > > > > > > > > - CONFIG_BLUETOOTH_UART > > > > > - CONFIG_BLUETOOTH_RPMSG > > > > > - CONFIG_BLUETOOTH_NULL > > > > > > > > > > So I think it is possible to make the three options coexist on > NuttX, > > > as > > > > > long as we keep the host-stack selection separated and avoid > enabling > > > two > > > > > host stacks for the same controller path at the same time. If > needed, > > > we > > > > > can also make this more explicit by adding a Kconfig choice or > mutual > > > > > exclusion between the host stacks. > > > > > > > > > > Regarding the location, I understand your point about libs/zblue. > > > > However, > > > > > for the initial version, I still think keeping the full stack under > > > > net/bt > > > > > is the safer integration path. > > > > > > > > > > The reason is that splitting it into libs/zblue is not only a > directory > > > > > rename. To do that correctly, we need to isolate each profile and > data > > > > path > > > > > according to its own characteristics. Some profiles are not just > pure > > > > > userspace library logic. For example, SCO and LE Audio / ISO have > > > > > lower-level data paths. On Linux, part of this kind of traffic is > > > handled > > > > > or forwarded by the kernel side. So if we move everything to > libs/zblue > > > > too > > > > > early, we may create an artificial boundary that is not correct for > > > those > > > > > lower-level profiles. > > > > > > > > > > My suggestion is: > > > > > > > > > > 1. Keep the initial version integrated under net/bt, so the > > > > controller, > > > > > HCI, L2CAP, ISO/SCO and profile paths can work correctly first. > > > > > 2. Make the stack name clear as zblue if the community prefers > that, > > > > so > > > > > it is not presented as replacing the existing NuttX BLE stack. > > > > > 3. Keep the Kconfig separation so users can choose between: > > > > > - zblue-based stack, > > > > > - existing NuttX BLE stack, > > > > > - NimBLE userspace stack. > > > > > 4. After the initial integration is stable, we can evaluate > moving > > > or > > > > > splitting parts into libs/zblue profile by profile, where the > > > boundary > > > > > is > > > > > technically clear. > > > > > > > > > > So yes, I think it is possible to modify the PR to let both stacks > plus > > > > > NimBLE work on NuttX without interfering with each other. I just > think > > > > > doing a full libs/zblue separation as the first step may be risky, > > > > > especially for the lower-level profiles and audio-related paths. > > > > > > > > > > Does this direction sound acceptable to you? > > > > > > > > > > BR, > > > > > > > > > > Alan C. Assis <[email protected]> 于2026年10月22日周四 19:32写道： > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
