Hi Anchao, Yes, it was 5 or 6 years ago when Xiang tried to submit it to NuttX.
I still don't like the idea of using ZBlue on NuttX very much, but having it inside the kernel is even worse than having it in userspace. Just like other people voting I'm not an expert on Bluetooth, but I think the point here is having a surface area of almost 1 million lines of code inside the kernel. As I pointed out on your PR, Bluetooth technology by itself is very faulty and prone to bugs! Let me put it another way: Bluetooth is "inherently broken and riddled with bugs"! Why am I saying that? The specification by itself is very complex and huge, exceeding 3000 pages and each new version increases this size. Since its conception it was developed for convenience, not for security purposes! Of course, security has improved over more than 20 years, but it is still far from ideal. There is a nice article about this subject here: https://medium.com/@legionoffensivesec/breaking-the-airwaves-how-attackers-exploit-bluetooth-iot-wireless-devices-in-the-real-world-925870f00bb6 BR, Alan On Mon, Nov 2, 2026 at 10:22 AM chao an <[email protected]> wrote: > Hi all, > > I think there is no need to continue voting on my proposal anymore. > > I have decided to give up on PR #20686: > https://github.com/apache/nuttx/pull/20686 > > From my point of view, the community has already moved away from some of > the original technical principles that Greg had for NuttX. I also feel that > there are now too many people directing the technical direction, but not > enough people actually doing the technical work. > > What disappoints me even more is that some of the people voting on this > topic are not really from the Bluetooth area, yet they are making decisions > on the Bluetooth architecture. This makes it very difficult for me to > continue investing my time in this direction. > > Alan, I also want to ask one question directly: do you still remember that > you once rejected the same approach that you are now supporting? > > BRs, > > Xiang Xiao <[email protected]> 于2026年11月2日周一 20:50写道： > > > +1 for 1b and 2b. > > The goal is improving the original BLE only stack with BT/BLE capability, > > but https://github.com/apache/nuttx/pull/20686 is still in the very > early > > stage > > and then far from to enter the kernel space. > > The reasonable and smooth migration approach is that: > > > > 1. Integrate Zephyr bluetooth stack in the userspace and setup > > CI/CT/simulation, so the community could get a mature, stable and full > > feature BT/BLE stack immediately > > 2. Move L2/L3 of the stack from userspace to kernel and improve the > > origin stack directly and make all user space examples and tools work > as > > before > > 3. Modify the userspace stack invoking the kernel function through > > socket interfaced and drop L2/L3 code in the userspace > > > > We can check and verify the result of each step independently. > > > > Thanks > > Xiang > > > > > > On Mon, Nov 2, 2026 at 7:47 PM chao an <[email protected]> wrote: > > > > > Hi all, > > > > > > Since my proposal is part of the options being voted on, I think I > > > should probably not cast a vote myself. > > > > > > However, I would like to add one clarification for option 1A. > > > > > > The performance benefit is only one part of the motivation. The > > > long-term goal of 1A is not just to reduce context switches or data > > > copies, but to make this a true NuttX-native Bluetooth host > > > implementation. In the future, this direction can introduce proper > > > user/kernel-space primitives and interfaces for protected and kernel > > > builds, while keeping the core host integrated with the NuttX kernel > > > architecture. In other words, 1A is intended to become a real > > > Bluetooth protocol stack owned, maintained, reviewed, and evolved by > > > NuttX itself. > > > > > > For option 1B, I also want to mention that this was actually the first > > > approach I proposed to Greg six years ago: keep the Zephyr host mostly > > > unmodified in apps, add only the NuttX porting layer, and update it by > > > changing the pinned upstream revision. At that time, this approach was > > > rejected. > > > > > > So I am a bit confused now: if the community votes for 1B today, does > > > that mean the community disagrees with Greg’s previous position? If > > > this approach had been accepted back then, the zblue work could have > > > been introduced into the community six years ago. > > > > > > To be honest, I am very disappointed with how this decision process has > > > evolved. > > > > > > P.S. I still keep the repository from six years ago here: > > > https://github.com/anchao/zblue > > > > > > BRs, > > > > > > > > > Alin Jerpelea <[email protected]> 于2026年11月2日周一 19:26写道： > > > > > > > +1 for 1b > > > > > > > > Thanks for your hard work > > > > > > > > Beat regards > > > > Alin J > > > > > > > > On Mon, 2 Nov 2026, 12:20 Alan C. Assis, <[email protected]> wrote: > > > > > > > > > +1 for option 1B: ZBlue stack in user-space > > > > > > > > > > On Mon, Nov 2, 2026 at 6:39 AM 成凯 via dev <[email protected]> > > > wrote: > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > > > This is a vote on how a Zephyr-based Bluetooth host should be > > > > integrated > > > > > > into NuttX. On 29 October Matteo suggested moving to a vote, > > because > > > > the > > > > > > discussion was not producing new viewpoints. No vote thread has > > been > > > > > > started since then, so I am starting it here. > > > > > > > > > > > > Disclosure: I am one of the authors of the [DISCUSS] proposal > > (option > > > > 1B > > > > > > below). I have tried to describe both options in neutral terms, > > using > > > > the > > > > > > words of their authors where possible. If either side thinks the > > > > > > description of its option is not accurate, please reply in this > > > thread > > > > > > and I will post a corrected text. > > > > > > > > > > > > Discussion: > > > > > > - PR #20686: https://github.com/apache/nuttx/pull/20686 > > > > > > - [DISCUSS] thread: > > > > > > > https://lists.apache.org/thread/c6pl46o5l1ngb2zb3qtotq38o30h6v4b > > > > > > - Side thread: > > > > > > > https://lists.apache.org/thread/3qfsgtzxmor02r2onnc11m36wl7qvzc0 > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Not part of this vote > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > - Most replies prefer one Zephyr-based host rather than two > > different > > > > > > ports. Alin suggested keeping both implementations selectable > at > > > > > > build time; if you prefer that, please say so in your reply. > > > > > > - It is an optional stack selected by Kconfig. The existing NuttX > > > > > > Bluetooth stack and NimBLE stay available. > > > > > > - Bluetooth feature options keep the CONFIG_BT_* names. The name > of > > > the > > > > > > top-level switch is decided in review. > > > > > > - In protected and kernel builds, profiles, services, shell and > > tools > > > > run > > > > > > in userspace. > > > > > > - Tests in CI and correct license headers are required. > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Question 1: where does the host start? > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > [1A] PR #20686: adapted host in the NuttX kernel tree. > > > > > > The whole host is added to nuttx.git (today libs/zblue), > > adapted > > > > to > > > > > > NuttX coding style and NuttX APIs, and maintained by NuttX > as > > > its > > > > > > own code. Upstream Zephyr changes are picked up as needed. > > Flat > > > > > > builds are supported first. Higher-level profiles move to a > > > > library > > > > > > in userspace later, and a socket/VFS interface is added for > > > > > > protected and kernel builds. > > > > > > Arguments given: fewer context switches and data copies on > > small > > > > > > MCUs; direct access to kernel primitives; no large Zephyr > > > > > > compatibility layer; reviewed and tested as part of NuttX; > no > > > > > > external download. > > > > > > > > > > > > [1B] [DISCUSS] proposal: unmodified host in nuttx-apps. > > > > > > The host is added to nuttx-apps under > > wireless/bluetooth/zblue, > > > in > > > > > > the same way as NimBLE. The Zephyr host code is not > modified. > > It > > > > is > > > > > > fetched at a pinned revision and updated by changing the > > > revision. > > > > > > Only the port layer (Zephyr kernel APIs on top of NuttX, HCI > > > glue, > > > > > > build files) is NuttX code and is reviewed in nuttx-apps. At > > the > > > > > > start, the kernel provides only the HCI transport that > already > > > > > > exists (/dev/ttyHCIx). > > > > > > Arguments given: smaller kernel attack surface in protected > > and > > > > > > kernel builds; uses public interfaces only; same model as > > > NimBLE; > > > > > > upstream fixes, including security fixes, are picked up by > > > > changing > > > > > > the revision. > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Question 2: if 1B wins, what is the long-term kernel/user > boundary? > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > Everyone can answer this question, also if you vote 1A. It is > > counted > > > > > > only if 1B wins. It sets the direction only; each step is still a > > > > > > separate, reviewed patch series. > > > > > > > > > > > > [2A] HCI boundary. > > > > > > The whole host stays in nuttx-apps. The kernel keeps only > the > > > HCI > > > > > > transport and drivers. > > > > > > > > > > > > [2B] L2CAP boundary (Linux/BlueZ-style). > > > > > > HCI core, connection management and L2CAP move step by step > > into > > > > > > the NuttX kernel, replace the current kernel Bluetooth stack > > > > > > (wireless/bluetooth and net/bluetooth) without losing > > function, > > > > and > > > > > > are exposed through Bluetooth sockets. These layers are then > > > > > > maintained by NuttX. Profiles, services, shell and tools > stay > > in > > > > > > nuttx-apps. > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > How to vote > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > Please reply with one choice per question, for example: > > > > > > > > > > > > Q1: 1A or 1B > > > > > > Q2: 2A or 2B > > > > > > > > > > > > You can reply "0" for a question if you have no preference. A > short > > > > > > reason is welcome. Please keep the technical discussion in the > > > > [DISCUSS] > > > > > > thread, not in this one. > > > > > > > > > > > > Votes from PMC members are binding. Everyone else is welcome to > > vote > > > > too > > > > > > (non-binding). For each question, the option with more binding > > votes > > > > > > wins; Question 2 is counted only if 1B wins. If there is a tie, > the > > > > > > discussion continues in the [DISCUSS] thread. > > > > > > > > > > > > The vote is open until Monday, 9 November 2026, 00:00 UTC (more > > than > > > 72 > > > > > > hours), so that all time zones can take part. > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > After the vote > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > The result will be posted as [RESULT][VOTE]. Both sides have said > > > they > > > > > > will follow the community decision. The contributors then agree > on > > a > > > > > > short joint roadmap in the [DISCUSS] thread and send small, > > > reviewable > > > > > > patches that follow the result. > > > > > > > > > > > > Thank you, > > > > > > 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!******/# > > > > > > > > > > > > > > > > > > > > >
