Hi Anchao, You are right the files still available online: https://github.com/sergioamr/arduino101_firmware and Intel was already integrating it on Zephyr when Greg got it (but it was not entangled with Zephyr kernel APIs).
I truly believe it is possible to fix the performance issues you found when running it in userspace. BR, Alan On Thu, Oct 29, 2026 at 6:46 PM chao an <[email protected]> wrote: > Hi Alan, > > > > > > > > Regarding the origin of NuttX's native Bluetooth stack — the git history > speaks for itself. The commit message in Greg's original patch explicitly > states it was ported from the "Intel/Zephyr > arduino101_firmware_source-v1.tar package." That's recorded in the commit > history and can't be rewritten. Whatever the Intel donation timeline may > have been, the fact remains that the code's lineage traces directly to > Zephyr. > > > > > > Thank you for your perspective on zblue's development direction. However, > I still firmly believe it should stay in the kernel. We've already > encountered performance and scheduling bottlenecks with userspace Bluetooth > implementations in real projects — that's precisely why I want it in the > kernel. > > > > > > > Let me offer an analogy: in NuttX's kernel/flat build mode, the system > calls in libs/ already distinguish between syscall and direct function call > paths via macros. I'm very confident in my ability to make zblue work > correctly in both kernel and flat build modes — in fact, I'm already doing > it. > > BRs, > > Alan C. Assis <[email protected]> 于2026年10月30日周五 00:02写道： > > > Hi Anchao, > > > > That is not technically true: Intel donated the same BLE stack to Zephyr. > > Greg got it from the Intel Genuino project when it was still under the > BSD > > License. (Although both stacks have the same origin, it is different from > > saying that NuttX Bluetooth came from Zephyr). > > > > Regarding the ZBlue integration discussion, I think we should follow your > > suggestion of modifying the existing code instead of copying it > > periodically, as Xiaomi is doing. However, we can do this while keeping > it > > in nuttx-apps. > > > > I think only a small adapter layer should be on the kernel side (and that > > code should not contain any lines of code from zblue). > > > > BR, > > > > Alan > > > > On Thu, Oct 29, 2026 at 10:01 AM chao an <[email protected]> wrote: > > > > > Tomek, > > > > > > I think you should take a look at the history of NuttX's existing > native > > > Bluetooth stack. It was also ported from Zephyr by Greg Nutt — here's > the > > > original commit: > > > > > > > > > > > > https://github.com/apache/nuttx/commit/accef0ca9e96ced73ebe3e141975993edb52d42e > > > > > > That stack was brought in-tree, adapted to NuttX's APIs and threading > > > model, and evolved through many subsequent commits to fill in the > missing > > > pieces. This is exactly the same pattern I'm following with libs/zblue. > > So > > > I have to ask — do you also take issue with that earlier fork? Or were > > the > > > CVE concerns somehow not applicable back then? > > > > > > The precedent was set a long time ago. I'm not doing anything > > fundamentally > > > different. > > > > > > BRs, > > > > > > Tomek CEDRO <[email protected]> 于2026年10月29日周四 20:51写道： > > > > > > > === TLDR === > > > > > > > > Internal bluetooth stack seems perfect, but it comes from external > > > > code and active project with better maintenance capabilities thus we > > > > should not fork their code adapt it as our own and then jump into the > > > > maintenance nightmare of chasing the upstream rabbit both for updates > > > > and security fixes. > > > > > > > > ====== > > > > > > > > Just to have reference in this thread also based on discussion from > > > > https://github.com/apache/nuttx/pull/20686 > > > > > > > > Regarding architecture: > > > > * @anchao I think more people here (i.e. me, @jerpelea, @acassis, > > > > @xiaoxiang781216, @linguini1, ..) asks for keeping ZBlue as "external > > > > module". > > > > * I know you prefer to keep it "internal" and "adapted with time" but > > > > this may make maintenance harder in future. > > > > * We can clone a given zblue commit, then use "glue" to make it work > on > > > > NuttX. > > > > * That way we only adapt the "glue" while external implementation is > > > > "original" and can be very easily updated with only hash update. > > > > * This is especially important for security updates and reported CVEs > > > > - we have them for free and always updated with no additional work. > > > > * One thing to consider here is the 1. licensing (is it Apache??) and > > > > 2. software supply chain security (we may keep our local fork). > > > > > > > > Regarding nomenclature: > > > > * I like "CONFIG_BT*" prefix for all Bluetooth related. > > > > * Bluetooth in general would be enabled with `CONFIG_BT`. > > > > * I would then prefer `CONFIG_BT_ZBLUE` over `CONFIG_ZBLUE` because > > > > ZBlue jumps under the BT category. > > > > * Specific functionalities would then be provided by a selected > > > > implementation (i.e. zblue, nimble, nxbt) and could have overlappping > > > > names to provide the same "low level" stuff on their own - that would > > > > provide common API for the "higher level" user applications. > > > > > > > > We have friction in the architecture area - Anchao wants to keep the > > > > implementation "internal", while most folks prefer "external module". > > > > How can we solve this? > > > > > > > > For me there are two main issues: > > > > > > > > 1. Updates, maintenance, security - with "external module" we only > > > > need to update "glue" on our part while the (zblue) upstream provides > > > > the updates, functionalities, security fixes. When we take "zblue" > and > > > > make it "internal" we are forever tied to run after the upstream - > > > > which is a lot of additional work, security, compatibility, maybe > even > > > > certification problem - which sounds like a maintenance nightmare (or > > > > warm position for the maintainter but what happens when maintainer is > > > > gone?). > > > > > > > > 2. It does not sound okay to take some implementation and call it my > > > > own now while still planning on using their updates ;-) As Alan > stated > > > > ~90% of the code is original zblue and only small (but important) > part > > > > is the "glue". It sound more fair to keep the original code from the > > > > upstream and only maintain the "glue" part as our own. > > > > > > > > > > > > Plus I am adding Alan's precise remarks below quotation why Bluetooth > > > > Security and Maintenance is really important and why we should keep > > > > even ZBlue as external module, which I agree with. > > > > > > > > Thanks :-) > > > > Tomek > > > > > > > > > > > > On Sat, Oct 24, 2026 at 2:05 PM Alan C. Assis < > > [email protected]> > > > > wrote: > > > > > > > > > > acassis left a comment (apache/nuttx#20686) > > > > > > > > > > @anchao I think enhancing the native stack is always the best > option, > > > > because we got an implementation that is not the same code from a > > foreign > > > > project and are not affected by the same vulnerabilities. > > > > > > > > > > Just to prove my point, from 2019 until now were 73 vulnerabilities > > > > found on ZBlue: > > > > > (CVE-2019-9506, CVE-2020-10061, CVE-2020-10065, CVE-2020-10066, > > > > CVE-2020-10068, CVE-2020-10069, CVE-2021-3430, > > > > > CVE-2021-3431, CVE-2021-3432, CVE-2021-3433, CVE-2021-3434, > > > > CVE-2021-3435, CVE-2021-3436, CVE-2021-3454, > > > > > CVE-2021-3455, CVE-2021-3581, CVE-2021-3966, CVE-2022-1041, > > > > CVE-2022-1042, CVE-2022-2993, CVE-2022-3806, > > > > > CVE-2023-0396, CVE-2023-0397, CVE-2023-1901, CVE-2023-1902, > > > > CVE-2023-4258, CVE-2023-4264, CVE-2023-4424, > > > > > CVE-2023-5055, CVE-2023-5753, CVE-2024-1638, CVE-2024-3077, > > > > CVE-2024-3332, CVE-2024-4785, CVE-2024-5754, > > > > > CVE-2024-5931, CVE-2024-6135, CVE-2024-6137, CVE-2024-6258, > > > > CVE-2024-6259, CVE-2024-6442, CVE-2024-6443, > > > > > CVE-2024-6444, CVE-2024-8798, CVE-2025-7403, CVE-2025-9557, > > > > CVE-2025-9558, CVE-2025-10456, CVE-2025-10457, > > > > > CVE-2025-10458, CVE-2025-12035, CVE-2025-12890, CVE-2026-2411, > > > > CVE-2026-5068, CVE-2026-5589, CVE-2026-9263, > > > > > CVE-2026-10593, CVE-2026-10641, CVE-2026-10651, CVE-2026-10653, > > > > CVE-2026-10654, CVE-2026-10658, CVE-2026-10660 > > > > > CVE-2026-10675, CVE-2026-10680, CVE-2026-10685, CVE-2026-10774, > > > > CVE-2026-11368, CVE-2026-11893, CVE-2026-11894 > > > > > CVE-2026-12236, CVE-2026-13213, CVE-2026-15460, and counting) > > > > > > > > > > 21 only this year! You can think: good these are vulnerabilities > that > > > > were fixed and we will not be affected. The problem is the year > didn't > > > > finish, they will discover a lot more before the end of the year, and > > > many > > > > more in the coming years. > > > > > > > > > > And since Zephyr is becoming used in more products from different > > > > vendors (like Windows) it mean any product with NuttX will be > affected > > as > > > > well. > > > > > > > > > > Perhaps ZBlue could be a great stack (if you think so), but it > could > > it > > > > is a foreign code injected on NuttX in the most critical part of > NuttX > > > > (kernel), it means any vulnerability found on that stack will put a > > NuttX > > > > product in risk. > > > > > > > > > > This is why I suggested to add a Kconfig "Bluetooth Support" and > > inside > > > > it add: > > > > > > > > > > [] NuttX Native BLE stack (WIP) > > > > > [] ZBlue (Zephyr Bluetooth stack) > > > > > [] NimBLE stack > > > > > > > > > > I think we need to hear more from other developers, seems like only > > you > > > > and I are interested on it. > > > > > Ping @xiaoxiang781216 @raiden00pl @hartmannathan @jerpelea @cederom > > > > @michallenc @casaroli @simbit18 > > > > > > > > -- > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > On Thu, Oct 29, 2026 at 5:36 AM chao an <[email protected]> wrote: > > > > > > > > > > Hi Chengkai, > > > > > > > > > > Thanks for the clarification, I replied to you on GitHub: > > > > > > > > > > I think we are mostly aligned on the long-term direction, > especially > > > > about > > > > > converging to one Zephyr-based Bluetooth host and moving toward a > > > > > BlueZ/Linux-style split for protected/kernel builds. > > > > > > > > > > For open point 2, I still prefer not to start from an external > > > repository > > > > > model in the main NuttX integration path. > > > > > > > > > > My suggestion is that the code should first be adapted into a > > > > NuttX-native > > > > > integration style, and then submitted directly to either nuttx.git > or > > > > > nuttx-apps.git, depending on the agreed layering. Fetching a large > > > > external > > > > > repository at build time will also bring dependency and maintenance > > > > issues > > > > > with other third-party code, and I do not think that is the best > > > > long-term > > > > > integration model for an official NuttX Bluetooth stack. > > > > > > > > > > In my view, if the stack is going to become part of the NuttX > > Bluetooth > > > > > architecture, it should be reviewed, built, tested, and maintained > as > > > > part > > > > > of the NuttX repositories, not as an external component that is > only > > > > pinned > > > > > by revision. > > > > > > > > > > Maybe you can use the current PR as a reference for the > NuttX-native > > > > > integration structure: top-level CONFIG_ZBLUE_ENABLED, NuttX > > > > build/Kconfig > > > > > integration, NuttX-style public headers, and direct integration > with > > > the > > > > > NuttX Bluetooth driver path. The implementation details can > certainly > > > be > > > > > changed, but I think this kind of native integration is a better > > > > direction > > > > > than relying on an external fetched repository. > > > > > > > > > > If the openvela version is adjusted in this direction and accepted > by > > > the > > > > > community as the common upstream solution, I am willing to drop my > > > > current > > > > > PR and help with that effort. My goal is not to keep my own patch, > > but > > > to > > > > > help NuttX get a complete and maintainable Bluetooth stack. > > > > > > > > > > BRs, > > > > > > > > > > 成凯 via dev <[email protected]> 于2026年10月29日周四 10:46写道： > > > > > > > > > > > Hi anchao, > > > > > > > > > > > > Thank you for the detailed reply, and for the offer to work > > > > together. I > > > > > > am > > > > > > glad we agree on the most important point: NuttX should have > one > > > > > > Zephyr-based Bluetooth host, not two. > > > > > > > > > > > > Let me first list where I think we already agree, then the open > > > > points > > > > > > and > > > > > > a proposed order of work. > > > > > > > > > > > > Where we agree: > > > > > > > > > > > > 1. One common stack. We are happy to use the openvela stack as > > the > > > > common > > > > > > base and to work on it together with you. > > > > > > 2. Long-term architecture for protected/kernel builds: a > > > > > > BlueZ/Linux-style > > > > > > split, with HCI/core/L2CAP and socket integration in the > > kernel, > > > > and > > > > > > profiles, services and tools in userspace. This is the path > > > > described > > > > > > in > > > > > > Section 5 of the proposal. > > > > > > 3. Flat builds may keep a more direct HCI path (btdev callback) > > for > > > > > > low-end > > > > > > IoT chips. We see no conflict with that; it can be an option > > > next > > > > to > > > > > > the > > > > > > socket model. > > > > > > 4. Kconfig: CONFIG_ZBLUE_ENABLED as the top-level switch, with > > > > > > CONFIG_BT_* > > > > > > for the feature options, as agreed with Alan, is fine with > us. > > > > > > > > > > > > Open point 1: fork vs. staying in sync with Zephyr > > > > > > > > > > > > You are right that the port layer needs NuttX kernel-style > > > primitives > > > > > > today, and that the compatibility layer has a cost. In flat > build > > > we > > > > use > > > > > > some internal primitives; making the port layer use only public > > > > > > interfaces > > > > > > is part of the protected/kernel work. > > > > > > > > > > > > Our suggestion is to fork only where the NuttX architecture > > > requires > > > > it, > > > > > > not by default: > > > > > > > > > > > > - The layers that move into the kernel (HCI core, connection > > > > management, > > > > > > L2CAP, socket integration) become NuttX-maintained code. > Those > > > are > > > > the > > > > > > parts that must be adapted to NuttX networking, memory > > management > > > > and > > > > > > build modes anyway. > > > > > > - The layers above (profiles, GATT services, LE Audio, Mesh, > > > Classic > > > > > > profiles) only depend on the Zephyr Bluetooth host API, not > on > > > the > > > > > > Zephyr > > > > > > kernel. That is also where most upstream development and > > security > > > > fixes > > > > > > happen. Keeping them close to upstream lets NuttX keep > picking > > > > those > > > > > > fixes up with little effort. > > > > > > > > > > > > This way the compatibility layer shrinks over time instead of > > > > growing, > > > > > > and > > > > > > the divergence happens step by step, where it brings real > value. > > > > > > > > > > > > Open point 2: external repository vs. in-tree > > > > > > > > > > > > We suggest starting with an external git repository, fetched > at a > > > > pinned > > > > > > revision like NimBLE. This keeps the first patches small and > easy > > > to > > > > > > review, > > > > > > and gives everyone a working stack to test against from the > > start. > > > > The > > > > > > kernel part will live in nuttx.git. Once the userspace part > only > > > > contains > > > > > > the layers above L2CAP, we can move it into nuttx-apps.git if > the > > > > > > community > > > > > > prefers that. > > > > > > > > > > > > Proposed order of work: > > > > > > > > > > > > 1. Integrate the stack into nuttx-apps as an external git > > > > repository, as > > > > > > described in the proposal. > > > > > > 2. Move the L2CAP layer and below into the NuttX kernel, > > replacing > > > > the > > > > > > current kernel Bluetooth implementation (wireless/bluetooth > > and > > > > > > net/bluetooth). The new kernel part must keep the existing > > > > > > functionality > > > > > > and add BR/EDR Classic support. > > > > > > 3. Change the stack in nuttx-apps to drop its own > L2CAP-and-below > > > > layers > > > > > > and > > > > > > use the NuttX kernel instead (sockets for protected/kernel > > > > builds; for > > > > > > flat builds, optionally a direct function-call/callback path > > to > > > > the > > > > > > kernel L2CAP layer). If needed at this step, the remaining > > > > > > Zephyr-derived > > > > > > code can be moved into nuttx-apps.git. > > > > > > > > > > > > Each step is a separate series of small patches, and the stack > > > keeps > > > > > > working > > > > > > after every step. > > > > > > > > > > > > I would like to hear what Xiang, Alan, raiden00pl and others > > think > > > > about > > > > > > this order and the two points above. > > > > > > > > > > > > Proposed next step: once this is settled, we write a short > joint > > > > roadmap > > > > > > (owners and schedule for each step), post it here for review, > and > > > > then > > > > > > start with small, reviewable patches. > > > > > > > > > > > > Thanks again for the open discussion. > > > > > > > > > > > > Best regards, > > > > > > Kai Cheng > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: chao an <[email protected]> > > > > > > Sent: Wednesday, October 28, 2026 9:03 PM > > > > > > To: [email protected] > > > > > > Cc: 黄玉龙; 高子豪; 梁超众; 李剑; 陈建; 成凯 > > > > > > Subject: Re: [External Mail][DISCUSS] Proposal: integrate a > > > > Zephyr-based > > > > > > Bluetooth host (openvela zblue) as a userspace stack in > nuttx-apps, > > > > kept in > > > > > > sync with upstream Zephyr > > > > > > > > > > > > > > > > > > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 > > > > > > > > > > > > Hi Chengkai and Vela team, > > > > > > > > > > > > First, thank you for writing this proposal. I think this is a > good > > > > start: > > > > > > the community is now discussing the Bluetooth host stack > direction > > > > > > seriously, and that is very helpful for NuttX. > > > > > > > > > > > > I agree that we should converge on one Zephyr-based Bluetooth > host > > > > instead > > > > > > of maintaining two unrelated solutions. However, I have a > different > > > > view on > > > > > > the long-term implementation model. > > > > > > > > > > > > My current opinion is that once we import the Zephyr Bluetooth > host > > > > into > > > > > > NuttX, we should treat it more like a forked NuttX Bluetooth > stack, > > > > not as > > > > > > a subtree that keeps rebasing/syncing with Zephyr forever. > > > > > > > > > > > > The reason is that zblue is deeply coupled with the Zephyr kernel > > > > model. > > > > > > If we want to keep it continuously synchronized with Zephyr, then > > in > > > > > > practice we also need to keep a large Zephyr compatibility layer > > > > alive. For > > > > > > an official NuttX solution, I do not think it is ideal to > introduce > > > and > > > > > > maintain a large part of the Zephyr kernel abstraction just for > one > > > > > > protocol stack. > > > > > > > > > > > > Some comments on the questions: > > > > > > > > > > > > 1. About putting a userspace Zephyr host in nuttx-apps and > > > fetching > > > > it > > > > > > from an external repository while keeping it synchronized with > > > Zephyr: > > > > > > I still have concerns about this model. > > > > > > First, zblue is not really an independent userspace library. It > was > > > > > > designed to run inside Zephyr and depends heavily on Zephyr > kernel > > > > > > concepts. Even if it is placed in apps, the porting layer still > > needs > > > > many > > > > > > NuttX kernel-style primitives, such as nxsem, nxmutex, work > queues, > > > > ticks, > > > > > > timers, and internal scheduling behavior. So I do not think > simply > > > > placing > > > > > > it in nuttx-apps makes it a clean application-level library. > > > > > > Second, this does not match the original direction that Greg > wanted > > > for > > > > > > the NuttX Bluetooth stack. My understanding is that the goal was > a > > > > > > Unix-like Bluetooth architecture, where data communication goes > > > through > > > > > > network/socket APIs. A pure userspace Zephyr-style host over HCI > > does > > > > not > > > > > > really provide that architecture. > > > > > > Third, I think keeping full long-term synchronization with Zephyr > > > will > > > > be > > > > > > very difficult unless we preserve too much of Zephyr's own kernel > > > > model. > > > > > > Once we adapt the stack seriously to NuttX APIs, networking, > memory > > > > > > management, driver model, and build modes, it will naturally > > diverge. > > > > So I > > > > > > prefer to accept that it becomes a NuttX-maintained Bluetooth > stack > > > > based > > > > > > on Zephyr, rather than trying to keep it as an almost-unmodified > > > Zephyr > > > > > > module. > > > > > > 2. About where the external repository should live: > > > > > > My preference is not to maintain it as a separate external > > repository > > > > in > > > > > > the long term. I think it should be integrated directly into > either > > > > > > nuttx.git or nuttx-apps.git, depending on the final layering > > > decision. > > > > This > > > > > > makes review, CI, release management, and maintenance clearer for > > the > > > > NuttX > > > > > > community. > > > > > > 3. About coexistence with PR #20686: > > > > > > I am very happy to drop my current PR if the community agrees on > a > > > > better > > > > > > common direction. My original goal is not to push my own > > > > implementation, > > > > > > but to help NuttX get a complete Bluetooth stack and improve the > > > > > > kernel-side networking architecture. > > > > > > If the openvela roadmap is aligned with that goal, especially if > it > > > can > > > > > > eventually support a Unix-like Bluetooth model for NuttX, I would > > be > > > > very > > > > > > happy to work with you and use your solution as the base. > > > > > > 4. About Kconfig naming: > > > > > > I discussed this with Alan before. The current compromise is to > > use a > > > > > > global switch like CONFIG_ZBLUE_ENABLED, while keeping the > internal > > > > Kconfig > > > > > > options close to Zephyr style, such as CONFIG_BT_*. I think this > is > > > > > > friendly to both Zephyr and Linux Bluetooth developers, while > still > > > > making > > > > > > the top-level NuttX feature explicit. > > > > > > 5. About the long-term split: > > > > > > My preference is: > > > > > > * For protected/kernel builds, move toward a > > BlueZ/Linux-style > > > > > > split: kernel-side HCI/core/L2CAP/socket integration, with > profiles > > > and > > > > > > tools in userspace. > > > > > > * For flat builds, allow a more direct HCI/btdev callback > > path > > > > for > > > > > > better performance on low-end IoT chips. > > > > > > In other words, I do not think we need one single boundary for > all > > > > build > > > > > > modes. NuttX supports very different deployment models, so the > > > > Bluetooth > > > > > > architecture may also need to support different integration > paths. > > > > > > > > > > > > Again, thanks for proposing this. I think the most important > thing > > is > > > > to > > > > > > reach a common direction first. I am open to working together and > > > > adjusting > > > > > > my PR if we can agree on a roadmap that gives NuttX a complete > > > > Bluetooth > > > > > > stack while also moving toward the right long-term architecture. > > > > > > > > > > > > BRs, > > > > > > > > > > > > 成凯 via dev <[email protected]<mailto:[email protected]>> > > > > > > 于2026年10月28日周三 20:46写道： > > > > > > Hi all, > > > > > > > > > > > > Apologies for the garbled characters in my previous mail; my > > mail > > > > > > client > > > > > > used a non-UTF-8 encoding. The "??5" / "��5" references mean > > > > "Section > > > > > > 5" > > > > > > (Optional path to a BlueZ/Linux-style split), "Section 7" is > > the > > > > Plan, > > > > > > and > > > > > > the dashes in the phase titles are plain hyphens. The content > > is > > > > > > otherwise > > > > > > unchanged. > > > > > > > > > > > > Please also ignore the confidentiality footer added by our > mail > > > > > > gateway; > > > > > > this proposal is intended for public discussion. > > > > > > > > > > > > Best regards, > > > > > > Kai Cheng > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: 成凯 via dev <[email protected]<mailto: > [email protected] > > >> > > > > > > Sent: Wednesday, October 28, 2026 5:54 PM > > > > > > To: [email protected]<mailto:[email protected]> > > > > > > Cc: 黄玉龙; 高子豪; 梁超众; 李剑; 陈建; 成凯 > > > > > > Subject: [External Mail][DISCUSS] Proposal: integrate a > > Zephyr-based > > > > > > Bluetooth host (openvela zblue) as a userspace stack in > nuttx-apps, > > > > kept in > > > > > > sync with upstream Zephyr > > > > > > > > > > > > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected] > > <mailto: > > > > > > [email protected]>进行反馈 > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Following the discussion on PR #20686 [1] and the thread "PR > > #20686 — > > > > > > Introducing > > > > > > a Zephyr-based Bluetooth host stack under net/bt" [2], I would > like > > > to > > > > > > propose an > > > > > > alternative integration model for a full-featured (BLE + BR/EDR > > > > Classic) > > > > > > Bluetooth host on NuttX, and ask for the community's opinion > before > > > we > > > > > > start > > > > > > sending patches. > > > > > > > > > > > > First, thanks to Archer (anchao) for pushing this topic forward. > > > > Everyone > > > > > > in the > > > > > > thread seems to agree that NuttX needs a more complete Bluetooth > > > host. > > > > The > > > > > > open > > > > > > question is where it should live and how it should be maintained. > > > This > > > > > > proposal > > > > > > only covers that question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 1. Summary > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > - Integrate the Zephyr Bluetooth host as a userspace library in > > > > nuttx-apps, > > > > > > under wireless/bluetooth/, the same way NimBLE is integrated > > today > > > > [3]. > > > > > > - The stack source lives in a standalone repository and is > fetched > > > at a > > > > > > pinned > > > > > > revision at build time. Zephyr's subsys/bluetooth is kept > > > > unmodified; all > > > > > > NuttX adaptation goes into a separate, small port layer. > > > > > > - At the start, the NuttX kernel only provides the HCI transport > > (the > > > > > > existing drivers/wireless/bluetooth bt_driver_s drivers, > exposed > > to > > > > > > userspace through the H4 character device or the HCI > user-channel > > > > > > socket). > > > > > > If the community prefers a BlueZ/Linux-style split, the L2/L3 > > > layers > > > > can > > > > > > be > > > > > > moved into the kernel step by step from this base (see §5). > > > > > > - The stack is an optional choice selected by Kconfig, next to > the > > > > native > > > > > > wireless/bluetooth stack and NimBLE. It does not replace them, > > and > > > > it is > > > > > > not > > > > > > presented as the default NuttX Bluetooth stack. > > > > > > - Fixes go to upstream Zephyr first and come back to NuttX > through > > > > regular > > > > > > rebases. > > > > > > > > > > > > If the community agrees with this direction, we will upstream our > > > > existing, > > > > > > production-proven stack step by step (stack integration first, > then > > > > tests, > > > > > > then the optional Bluetooth service layer). > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 2. What we already have > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > The openvela team at Xiaomi has run a Zephyr-based Bluetooth host > > on > > > > > > NuttX/openvela in production for some time: > > > > > > > > > > > > - Baseline: Zephyr v4.0 (upstream commit 2efc8598e39, 2024-11), > > plus > > > > later > > > > > > upstream fixes and our own work. > > > > > > - Features: LE GAP/GATT/ATT/SMP, and BR/EDR Classic with A2DP > > > > (SRC/SNK), > > > > > > AVRCP (CT/TG), HFP (AG/HF), SPP/RFCOMM, SDP, HID Device/Host > and > > > > > > GATT over BR/EDR. LE Audio and Mesh come from upstream. > > > > > > - Products: shipping in smart speakers (since 2025), smart > panels, > > > and > > > > > > wearables (watches and bands). > > > > > > - Qualification: Bluetooth SIG qualification against Core 6.2 > > > > (Declaration > > > > > > ID > > > > > > Q386483). > > > > > > - Qualification testing: the stack plugs directly into AutoPTS > > > through > > > > the > > > > > > Zephyr BTP tester. A full dual-mode qualification test run > takes > > > > about > > > > > > 2 person-days. > > > > > > - Simulation: conformance tests can run in simulation on BSWorld > > or a > > > > > > software RF controller, without real hardware or phones. This > is > > > key > > > > to > > > > > > keeping the stack's quality up as it evolves. > > > > > > - Performance: the host runs in userspace in a flat build and > > reaches > > > > about > > > > > > 210 kB/s SPP throughput on a wearable SoC. Running outside the > > > kernel > > > > > > has not > > > > > > been a bottleneck for us. > > > > > > - Upstream work: our team is one of the major contributors to > > Classic > > > > > > Bluetooth in the Zephyr community. > > > > > > - Public code: https://github.com/open-vela/external_zblue > (stack) > > > and > > > > > > https://github.com/open-vela/frameworks_bluetooth (service > > layer). > > > > These > > > > > > repositories contain our 2025 changes. The 2026 changes are > still > > > in > > > > our > > > > > > internal tree and will be released and upstreamed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 3. Points raised in the PR #20686 discussion > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > My reading of the review comments and the mailing-list thread: > > > > > > > > > > > > a) Profiles, shell commands and other application-level code do > not > > > > belong > > > > > > in > > > > > > kernel space (Xiang Xiao, raiden00pl). > > > > > > b) A monolithic third-party host stack should live in nuttx-apps > > or a > > > > > > separate > > > > > > git, integrated by download like NimBLE (Xiang Xiao). > > > > > > c) A stack of this size is a large attack surface. Keeping it out > > of > > > > the > > > > > > kernel > > > > > > protects at least protected and kernel builds (Alan Carvalho > de > > > > Assis, > > > > > > casaroli). > > > > > > d) It should be one selectable option, not the implicit > "official" > > > > NuttX > > > > > > Bluetooth stack (Alan Carvalho de Assis). > > > > > > e) Tests are required, e.g. sim-based or BSWorld (LingaoM, > > cederom). > > > > > > f) Copyright and license headers of the imported code must be > > handled > > > > > > correctly (jerpelea, acassis, Xiang Xiao). > > > > > > g) Unfinished work should not land on master (raiden00pl, Xiang > > > Xiao). > > > > > > > > > > > > The proposal below tries to meet all of these. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 4. Proposed architecture > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > +----------------------------------------------------------+ > > > > > > | Applications / btshell / (optional) Bluetooth service | > > > > userspace > > > > > > +----------------------------------------------------------+ > > > > > > | Zephyr Bluetooth host (unmodified subsys/bluetooth) | > > > > userspace > > > > > > | GAP/GATT/SMP/L2CAP/RFCOMM/SDP/A2DP/AVRCP/HFP/HID/... | > > > > > > (nuttx-apps) > > > > > > +----------------------------------------------------------+ > > > > > > | Port layer: k_thread/k_sem/k_work/k_timer, net_buf, | > > > > userspace > > > > > > | settings backend, logging, iterable sections, HCI glue | > > > > > > +=========================== HCI =========================+ > > > > > > | HCI transport: /dev/ttyHCIx (H4) or HCI user channel | > > > > kernel > > > > > > | bt_uart / bt_rpmsghci / bt_slip / sim HCI socket ... | > > > > > > (existing) > > > > > > +----------------------------------------------------------+ > > > > > > | Controller | > > > > > > +----------------------------------------------------------+ > > > > > > > > > > > > Design rules: > > > > > > > > > > > > 1. Upstream code stays unmodified. Zephyr's subsys/bluetooth is > not > > > > > > reformatted > > > > > > or edited in place. Like NimBLE, it is third-party code and > not > > > > subject > > > > > > to > > > > > > nxstyle. Any change the stack needs is sent to Zephyr first. > (If > > > > parts > > > > > > are > > > > > > later moved into the kernel as described in §5, those parts > are > > > > > > maintained > > > > > > in NuttX; the rest keeps this rule.) > > > > > > 2. NuttX adaptation stays in the port layer. Zephyr kernel APIs > are > > > > > > implemented > > > > > > on top of NuttX. Upstream Bluetooth code keeps calling the > > Zephyr > > > > API, > > > > > > so > > > > > > upstream patches still apply. > > > > > > 3. The initial kernel/user boundary is HCI. The only kernel > > component > > > > is > > > > > > the > > > > > > HCI transport, which NuttX already has. The host stack uses > > public > > > > > > interfaces only (open/read/write/poll or the HCI socket). > > > > > > 4. Kconfig is namespaced. One top-level option (e.g. > CONFIG_ZBLUE, > > > like > > > > > > CONFIG_NIMBLE) selects the stack. The Zephyr CONFIG_BT_* > feature > > > > options > > > > > > live under it inside nuttx-apps. If a kernel-side stack also > > uses > > > > > > CONFIG_BT_*, the two must be made mutually exclusive or > renamed; > > > we > > > > are > > > > > > happy to work this out with Archer. > > > > > > 5. Build modes: flat build first. Because only public interfaces > > are > > > > used, > > > > > > we > > > > > > plan protected and kernel build support as a follow-up phase > > (see > > > > §7). > > > > > > > > > > > > Why we start with the split at HCI: > > > > > > > > > > > > The Zephyr host is not layered like Linux. L2CAP is tightly > coupled > > > > with > > > > > > conn.c, ATT, SMP and the buffer and work-queue model. Splitting > at > > > HCI > > > > > > keeps > > > > > > the upstream code untouched and gives NuttX a complete, working > > stack > > > > from > > > > > > day one. It is the same model Android uses (a userspace host on > top > > > of > > > > an > > > > > > HCI > > > > > > transport) and the model NimBLE already uses on NuttX. Moving > L2CAP > > > and > > > > > > below > > > > > > into the kernel (the BlueZ model) is possible, but it means > > > > restructuring > > > > > > those layers, so we propose it as a separate, step-by-step path > > (§5). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 5. Optional path to a BlueZ/Linux-style split > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > Some community members prefer the Linux/BlueZ layering, where the > > > lower > > > > > > protocol layers (HCI core, connection management, L2CAP, and > > possibly > > > > SMP) > > > > > > live in the kernel and are exposed through AF_BLUETOOTH sockets, > > > while > > > > > > profiles, services and tools stay in userspace. This proposal is > > > > compatible > > > > > > with that goal, and our stack can serve as the base for it. > > > > > > > > > > > > The difference from PR #20686 is the direction of migration: > > > > > > > > > > > > - PR #20686 puts the whole host into the kernel first and plans > > to > > > > move > > > > > > parts back to userspace later. > > > > > > - We start with a complete, product-proven host in userspace, > and > > > > move > > > > > > the > > > > > > L2/L3 layers into the kernel step by step, only where the > > > community > > > > > > agrees. > > > > > > > > > > > > Every intermediate state is a working stack, every step can be > > > > reviewed and > > > > > > tested on its own, and the code that has not moved yet keeps > > tracking > > > > > > upstream Zephyr. > > > > > > > > > > > > Possible steps, each a separate patch series: > > > > > > > > > > > > 1. Define the kernel/user interface first: AF_BLUETOOTH sockets > > for > > > > L2CAP > > > > > > (BTPROTO_L2CAP, struct sockaddr_l2), building on the > existing > > > > NuttX > > > > > > definitions in include/netpacket/bluetooth.h, plus an HCI > > > > management > > > > > > interface. > > > > > > 2. Move the HCI core and connection management into the kernel, > > > next > > > > to > > > > > > the existing HCI drivers. > > > > > > 3. Move L2CAP (LE and BR/EDR) into the kernel behind the socket > > > > > > interface. > > > > > > 4. Decide case by case for SMP, ATT/GATT and RFCOMM, based on > > > review > > > > and > > > > > > measurements. > > > > > > > > > > > > What stays in nuttx-apps in all cases: profiles (A2DP, AVRCP, > HFP, > > > HID, > > > > > > ...), GATT services, the Bluetooth service layer, shell and > tools. > > > > > > > > > > > > Trade-off: code moved into the kernel will diverge from upstream > > > > Zephyr and > > > > > > must be maintained in NuttX. Moving it layer by layer, and > keeping > > > the > > > > > > Zephyr API at the boundary where possible, limits that cost and > > lets > > > > the > > > > > > community decide how far to go. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 6. Comparison with PR #20686 > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > PR #20686 (current) This > > proposal > > > > > > Location nuttx (net/bt, now libs/) > nuttx-apps + > > > > > > external repo > > > > > > Upstream code reformatted, Zephyr APIs > unmodified; > > > port > > > > > > layer only > > > > > > replaced in place > > > > > > Zephyr sync close to a re-port per rebase > onto > > > new > > > > > > Zephyr > > > > > > release (author describes releases > > > > > > it as a fork) > > > > > > Security fixes backported by hand picked > from > > > > upstream > > > > > > Kernel attack surface whole host in kernel HCI > > transport > > > > only > > > > > > Shell / profiles inside kernel tree userspace > > > > > > Build modes flat only flat > first, > > > then > > > > > > > > > protected/kernel > > > > > > License headers need rewriting in tree upstream > > files > > > > keep > > > > > > their > > > > > > headers, > not > > > in > > > > > > nuttx.git > > > > > > Evolution path whole host in kernel first, working > host > > > in > > > > > > userspace > > > > > > then move parts out first, > then > > > move > > > > > > L2/L3 > > > > > > into > kernel > > if > > > > > > agreed > > > > > > > > > > > > Notes: > > > > > > > > > > > > - Sync cost: the PR reformats the code to nxstyle and replaces > > Zephyr > > > > > > kernel > > > > > > APIs inside protocol files. A whitespace-insensitive diff > against > > > > > > Zephyr v4.5.0-rc1 still differs in roughly 19% of lines, so > > > upstream > > > > > > patches > > > > > > no longer apply directly. Archer also wrote on the PR that he > > does > > > > not > > > > > > expect > > > > > > to keep synchronizing with Zephyr ("more like forking"). For a > > code > > > > base > > > > > > this > > > > > > size, with a steady stream of upstream CVE fixes (Alan listed > > more > > > > than > > > > > > 70 > > > > > > since 2019), we think staying close to upstream is the main > > > long-term > > > > > > value. > > > > > > - Performance: as Xiang pointed out, in a flat build a userspace > > > stack > > > > has > > > > > > the > > > > > > same direct-call cost as an in-kernel one. The remaining > > per-packet > > > > > > overhead > > > > > > is the HCI transport (VFS + one copy). Our static estimate on a > > > > wearable > > > > > > SoC > > > > > > is a few KB of RAM and negligible CPU. Very constrained parts > > (for > > > > > > example > > > > > > the 80 MHz M0 / 64 KB case Archer described) can get an > optional > > > > > > flat-build-only direct HCI binding later, without moving the > host > > > > into > > > > > > the > > > > > > kernel. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 7. Plan > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > Phase 0 – Consensus (this thread) > > > > > > Agree on location, naming, Kconfig namespace and coexistence > with > > > PR > > > > > > #20686. > > > > > > > > > > > > Phase 1 – Stack integration (nuttx-apps) > > > > > > - wireless/bluetooth/zblue: Makefile/CMake download at a pinned > > > ref, > > > > > > Kconfig, > > > > > > port layer. > > > > > > - Uses the existing HCI transports; no kernel changes expected > > > (only > > > > > > small, > > > > > > separate fixes if any). > > > > > > - btshell as an NSH builtin (the Zephyr shell, Classic and LE > > > > commands). > > > > > > - sim configuration with a host HCI dongle, built in CI. > > > > > > > > > > > > Phase 2 – Tests > > > > > > - sim-based tests for LE and Classic in CI (BSWorld > integration). > > > > > > - AutoPTS support through the Zephyr BTP tester. > > > > > > - Samples: LE peripheral/central, A2DP sink, HFP HF, SPP. > > > > > > > > > > > > Phase 3 – Protected / kernel build > > > > > > - Port layer audited to use only public NuttX/POSIX interfaces. > > > > > > - Validated on a protected and a kernel build target. > > > > > > > > > > > > Phase 4 – Bluetooth service layer (optional) > > > > > > - Upstream the openvela Bluetooth service ("btservice"): a > > stable C > > > > API > > > > > > for > > > > > > applications, multi-client IPC, and a stack abstraction > layer, > > so > > > > > > applications do not depend on the host stack API. > > > > > > > > > > > > Phase 5 – Boards > > > > > > - Board configurations with real controllers (UART / RPMsg > HCI). > > > > > > > > > > > > Phase 6 – L2/L3 migration to the kernel (optional, if agreed) > > > > > > - Follow the steps in §5, one layer per patch series. > > > > > > > > > > > > Ongoing > > > > > > - Track Zephyr releases and send fixes upstream first. > > > > > > - We will provide maintainers for the integration. > > > > > > > > > > > > The main goal of this mail is to collect feedback on the > direction. > > > We > > > > will > > > > > > follow up with a detailed effort estimate and schedule for each > > phase > > > > once > > > > > > the > > > > > > direction is agreed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 8. Licensing > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > - Zephyr-derived files stay in the external repository with their > > > > original > > > > > > Apache-2.0 headers and SPDX tags. They are not copied into > > > > apache/nuttx > > > > > > or > > > > > > apache/nuttx-apps. > > > > > > - New glue code in nuttx-apps uses the standard ASF header and is > > > > > > contributed > > > > > > under ICLA/CCLA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > 9. Questions for the community > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > 1. Is a userspace Zephyr-based host in nuttx-apps, fetched from > an > > > > external > > > > > > repository and kept in sync with Zephyr, acceptable as the > > > > integration > > > > > > model? > > > > > > 2. Where should the external repository live (open-vela GitHub > > > > > > organization, > > > > > > or another location the PMC prefers)? > > > > > > 3. How should this coexist with PR #20686? We would rather > converge > > > on > > > > one > > > > > > Zephyr-based host than ship two. We are glad to work with > Archer > > > on > > > > a > > > > > > common approach. > > > > > > 4. Any preference on the top-level Kconfig name (CONFIG_ZBLUE or > > > > other)? > > > > > > 5. Should the long-term target stay at the HCI split, or move > > towards > > > > the > > > > > > BlueZ/Linux-style split described in §5? > > > > > > > > > > > > Feedback is very welcome. > > > > > > > > > > > > [1] https://github.com/apache/nuttx/pull/20686 > > > > > > [2] > > https://www.mail-archive.com/[email protected]/msg15328.html > > > > > > [3] > > > > > > > > > > > > > > > > https://github.com/apache/nuttx-apps/tree/master/wireless/bluetooth/nimble > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Kai Cheng > > > > > > > > > > > > > > > > > > > > > > > > > > > > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > > > > > > This e-mail and its attachments contain confidential information > > from > > > > > > XIAOMI, which is intended only for the person or entity whose > > address > > > > is > > > > > > listed above. Any use of the information contained herein in any > > way > > > > > > (including, but not limited to, total or partial disclosure, > > > > reproduction, > > > > > > or dissemination) by persons other than the intended recipient(s) > > is > > > > > > prohibited. If you receive this e-mail in error, please notify > the > > > > sender > > > > > > by phone or email immediately and delete it!******/# > > > > > > > > > > > > > > > > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > > > > > > This e-mail and its attachments contain confidential information > > from > > > > > > XIAOMI, which is intended only for the person or entity whose > > address > > > > is > > > > > > listed above. Any use of the information contained herein in any > > way > > > > > > (including, but not limited to, total or partial disclosure, > > > > reproduction, > > > > > > or dissemination) by persons other than the intended recipient(s) > > is > > > > > > prohibited. If you receive this e-mail in error, please notify > the > > > > sender > > > > > > by phone or email immediately and delete it!******/# > > > > > > > > > > > > > > > > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > > > > > > This e-mail and its attachments contain confidential information > > from > > > > > > XIAOMI, which is intended only for the person or entity whose > > address > > > > is > > > > > > listed above. Any use of the information contained herein in any > > way > > > > > > (including, but not limited to, total or partial disclosure, > > > > reproduction, > > > > > > or dissemination) by persons other than the intended recipient(s) > > is > > > > > > prohibited. If you receive this e-mail in error, please notify > the > > > > sender > > > > > > by phone or email immediately and delete it!******/# > > > > > > > > > > > > > > > > > > > >
