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