Hello all,
The vote on the integration model for a Zephyr-based Bluetooth host is
closed. Option 1B has passed, and 2B is the direction for the long-term
boundary.
Question 1: starting point
[1B] unmodified host in nuttx-apps
+1 (binding): Alan Carvalho de Assis, Alin Jerpelea, Xiang Xiao,
Tomasz Cedro
[1A] PR #20686, adapted host in the NuttX kernel tree
none
Non-binding votes: none
Question 2: long-term kernel/user boundary (counted because 1B won)
[2B] L2CAP boundary (Linux/BlueZ-style)
+1 (binding): Xiang Xiao, Tomasz Cedro ("probably [2B]")
[2A] HCI boundary
none
Chao An did not vote, as the author of option 1A, and has since closed
PR #20686. Nathan Hartman did not vote and leaves the decision to the
community.
The vote was open from 2 November to 9 November, 00:00 UTC:
https://lists.apache.org/thread/9fy6bog3dcw3do5d8wd0yyvlpkjrhxpn
The first PR of step 1 is apache/nuttx-apps#3977 with
apache/nuttx#21479, tracked in apache/nuttx#21478. Each later step is a
separate series and is reviewed on its own; 2B sets the direction, and
the details of step 2 will be discussed on its PRs.
Thank you all for your votes, and thank you Chao An for PR #20686 and
the discussion.
Kai Cheng
________________________________
From: 成凯
Sent: Monday, November 2, 2026 5:38 PM
To: [email protected]
Subject: [VOTE] Integration model for a Zephyr-based Bluetooth host in NuttX
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!******/#
