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