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