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!******/# > > > > >
