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