If https://github.com/apache/nuttx/pull/20686 do like [2B]:
1. Only L2/L3 keep in the kernel 2. Integrate with network socket architecture 3. Replace BLE only stack with BT/BLE stack and compatible with userspace tools/examples Most people including me will support it without any concern, but it isn't. On Mon, Nov 2, 2026 at 9:21 PM chao an <[email protected]> wrote: > Hi all, > > I think there is no need to continue voting on my proposal anymore. > > I have decided to give up on PR #20686: > https://github.com/apache/nuttx/pull/20686 > > From my point of view, the community has already moved away from some of > the original technical principles that Greg had for NuttX. I also feel that > there are now too many people directing the technical direction, but not > enough people actually doing the technical work. > > What disappoints me even more is that some of the people voting on this > topic are not really from the Bluetooth area, yet they are making decisions > on the Bluetooth architecture. This makes it very difficult for me to > continue investing my time in this direction. > > Alan, I also want to ask one question directly: do you still remember that > you once rejected the same approach that you are now supporting? > > BRs, > > Xiang Xiao <[email protected]> 于2026年11月2日周一 20:50写道： > > > +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!******/# > > > > > > > > > > > > > > > > > > > > >
