We now have part dev@ part github@ discussion :D I will reply my own GH response here on DEV@ too with a comment ;-)
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. Thanks :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Oct 29, 2026 at 1:13 PM chao an <[email protected]> wrote: > > Alan, > > First, I need to clarify an important point: Xiaomi's zblue approach is > completely different from what I submitted in PR #20686 > https://github.com/apache/nuttx/pull/20686. Xiaomi's version keeps Zephyr's > original headers and coding style largely intact, whereas my libs/zblue > submission is fully adapted for NuttX — headers restructured to > include/nuttx/net/bluetooth/, OS adaptation layer integrated, and the > entire tree reorganized to fit NuttX's build system. They are not the same > technical approach. > > I've already laid out the advantages of having the protocol stack in-tree > in PR #20686 — build integration, API cohesion, OS-level optimization > opportunities, and avoiding the friction of out-of-tree maintenance. > Reading your latest reply, I have to be honest: I'm disappointed, because > it feels like you haven't really engaged with what I was saying there. > > Regarding security — you keep raising this concern, and I want to address > it directly. Security issues are solvable. I don't just say this in the > abstract — I'm currently fixing 9 security vulnerabilities across NuttX's > networking and USB subsystems: > > 1. IPv6 extension-header out-of-bounds read — #20885 > https://github.com/apache/nuttx/pull/20885 > 2. MLDv2 report record-count out-of-bounds read — #20886 > https://github.com/apache/nuttx/pull/20886 > 3. ICMPv6 Router Advertisement prefix option out-of-bounds read — #20888 > https://github.com/apache/nuttx/pull/20888 > 4. USB host config-descriptor walk out-of-bounds read and infinite loop > — #21101 https://github.com/apache/nuttx/pull/21101 > 5. USB host composite copyinterface heap buffer overflow — #21101 > https://github.com/apache/nuttx/pull/21101 > 6. USB host composite member array out-of-bounds write — #21101 > https://github.com/apache/nuttx/pull/21101 > 7. CDC-MBIM NCM frame NDP/DPE walk out-of-bounds read and infinite loop > — #20884 https://github.com/apache/nuttx/pull/20884 > 8. USB mass-storage zero block size divide-by-zero in partition scan — > #21101 https://github.com/apache/nuttx/pull/21101 > 9. CDC-MBIM transmit divide-by-zero on zero bulk max packet size — > #20884 https://github.com/apache/nuttx/pull/20884 > > These are all in NuttX's own native code — networking, USB host, CDC — > subsystems I've worked on extensively. A CVE in any of these would likewise > disrupt devices in the field. Security is a universal concern for every > line of code we ship, regardless of its origin. We deal with it through > review, testing, and prompt fixes — exactly what I'm doing here. I > genuinely don't understand why you keep bringing this up as if it were > unique to zblue. > > > BRs, > > Alan C. Assis <[email protected]> 于2026年10月29日周四 19:38写道： > > > Hi Anchao and Chengkai, > > > > Thank you for moving this discussion forward. > > > > I think the agreement that NuttX should have only one Bluetooth stack (the > > Zephyr ZBlue stack) is not universally agreed upon, as we saw in the PR > > discussions. > > > > If NuttX selects only one BLE stack it should be its own stack (which is > > very limited currently and not a feasible option at this moment). > > > > Moving zblue to nuttx-apps and making it just an option like the NimBLE > > appears to be the right thing to do. > > > > It could be the stack that most people will use (instead of NimBLE or the > > native one), but it shouldn't be the only option because it shares almost > > 1M LoC from Zephyr and poses a huge security risk due to the monoculture > > effect: a CVE found on Zephyr ZBlue would disrupt all their devices on the > > field and also all NuttX devices using zblue. > > > > Imagine if Windows were open-source and someone in the Linux community > > decided to use the Windows windowing subsystem. It would make it very easy > > for vendors to implement graphical applications for both Windows and Linux, > > but any vulnerability found in Windows would affect Linux. That is > > basically the scenario here for NuttX. > > > > As I said I like the idea of having the option to use a Bluetooth stack > > like zblue until we evolve our own stack. > > > > BR, > > > > Alan > > > > On Thu, Oct 29, 2026 at 3:51 AM chao an <[email protected]> wrote: > > > > > Hi Chengkai, > > > > > > > > > > > > Thanks for the clarification. > > > > > > > > > > > > For question 1, by "NuttX-native integration" I mean more than only > > > Kconfig, > > > build glue, driver binding, and public headers. I think the > > Zephyr-derived > > > > > > Bluetooth host should be adapted into a NuttX-maintained stack, with a > > > > > > structure that can evolve toward the NuttX kernel/socket architecture. > > > > > > > > > > > > If we only keep the Zephyr Bluetooth source almost untouched and add a > > > large > > > compatibility layer around it, then I do not think that is the right > > > long-term > > > direction for the official NuttX Bluetooth architecture. > > > > > > > > > > > > For question 2, I think NimBLE and Zephyr Bluetooth are different cases. > > > > > > NimBLE officially provides an OS abstraction layer, so each OS can > > > integrate it > > > through its own OSAL. Zephyr Bluetooth does not provide the same OSAL > > > boundary; > > > it is deeply tied to the Zephyr kernel model. > > > > > > > > > > > > That means zblue needs many Zephyr kernel API/header compatibility > > pieces: > > > > > > kernel objects, work queues, timers, buffers, iterable sections, and > > other > > > > > > Zephyr-style assumptions. Even if placed in nuttx-apps, it is not really > > a > > > > > > clean standalone userspace library like NimBLE. > > > > > > > > > > > > My main concern is the long-term roadmap. If we preserve an almost > > > unmodified > > > Zephyr Bluetooth tree, then moving L2CAP and lower layers into the NuttX > > > > > > kernel later will be very difficult, because L2CAP is tightly coupled > > with > > > > > > connection management, buffers, work queues, ATT/SMP, and the Zephyr > > > execution > > > model. That migration may become close to a second rewrite. > > > > > > > > > > > > This is different from the current libs/zblue PR, where the stack is > > > already > > > treated as NuttX-maintained code and can diverge from Zephyr where the > > > NuttX > > > architecture requires it. > > > > > > > > > > > > So my concern is not only external repo vs in-tree. The bigger concern is > > > > > > whether we are building a real NuttX Bluetooth architecture, or mainly > > > keeping > > > a Zephyr runtime compatibility layer around the Zephyr Bluetooth stack. > > > > > > > > > > > > I agree this should be decided by the community, but my preference is > > still > > > to > > > adapt the code into a NuttX-native stack first, then submit it directly > > to > > > > > > nuttx.git or nuttx-apps.git depending on the agreed layering. > > > > > > BRs, > > > > > > 成凯 via dev <[email protected]> 于2026年10月29日周四 14:38写道： > > > > > > > hi anchao > > > > > > > > Thanks, good to see we are aligned on the direction. > > > > > > > > On open point 2, I think the difference is mainly about the starting > > > point, > > > > not the end state. We agree the stack should end up reviewed, built and > > > > tested as part of the NuttX repositories. Step 3 of the plan already > > > allows > > > > moving the userspace part into nuttx-apps.git. > > > > > > > > Two things I would like to understand better: > > > > > > > > 1. By "NuttX-style public headers" and "native integration", do you > > mean > > > > reformatting the Zephyr-derived code to nxstyle, or only the NuttX > > > glue > > > > (Kconfig, build, driver binding, public API headers)? We are fine > > with > > > > the > > > > latter. The former makes picking up upstream fixes much harder, > > which > > > is > > > > our main concern. > > > > 2. NimBLE is already integrated this way (download at a pinned > > revision). > > > > Could you share which specific dependency or maintenance issues you > > > are > > > > worried about? That would help us address them in the design. > > > > > > > > Since this is a project-level decision, I would like to hear from the > > PMC > > > > and everyone who has reviewed PR #20686 -- Xiang Xiao, Alan Carvalho de > > > > Assis, Alin Jerpelea, raiden00pl, Tomasz CEDRO (cederom), LingaoM and > > > > casaroli -- on whether to start with a pinned external repository or > > with > > > > in-tree code. We will follow the community's decision. > > > > > > > > Best regards, > > > > Kai Cheng > > > > > > > > > > > > ________________________________ > > > > From: archer <[email protected]> > > > > Sent: Thursday, October 29, 2026 12:19 PM > > > > To: apache/nuttx > > > > Cc: 成凯; Mention > > > > Subject: [External Mail]Re: [apache/nuttx] net/bt: Add native Bluetooth > > > > host stack (PR #20686) > > > > > > > > > > > > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 > > > > > > > > [https://avatars.githubusercontent.com/u/758493?s=20&v=4]anchao left a > > > > comment (apache/nuttx#20686)< > > > > https://github.com/apache/nuttx/pull/20686#issuecomment-6487811997> > > > > > > > > @chengkai15<https://github.com/chengkai15> > > > > > > > > Thanks for the clarification. 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. > > > > > > > > — > > > > Reply to this email directly, view it on GitHub< > > > > > > > > > https://github.com/apache/nuttx/pull/20686?email_source=notifications&email_token=ABDILOITAS5PRPRBASVZXOD5WLAN7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBYG44DCMJZHE32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6487811997 > > > >, > > > > or unsubscribe< > > > > > > > > > https://github.com/notifications/unsubscribe-auth/ABDILONP3W2NPDI7EX4JEGT5WLAN7AVCNFSNUABFKJSXA33TNF2G64TZHMZDEOBRGAZTENZTHNEXG43VMU5TKOBWG4ZTIMBYG4Z2C5QC > > > > >. > > > > You are receiving this because you were mentioned.Message ID: > > > > <apache/nuttx/pull/20686/[email protected]> > > > > > > > > > > > > > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > > > > 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!******/# > > > > > > > > >
