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