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