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