chengkai15 commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6471277070
Hi Archer,
Thank you for the detailed reply, and for the offer to work together. I am
glad we agree on the most important point: NuttX should have one
Zephyr-based Bluetooth host, not two.
Let me first list where I think we already agree, then the open points and
a proposed order of work.
Where we agree:
1. One common stack. We are happy to use the openvela stack as the common
base and to work on it together with you.
2. Long-term architecture for protected/kernel builds: a BlueZ/Linux-style
split, with HCI/core/L2CAP and socket integration in the kernel, and
profiles, services and tools in userspace. This is the path described in
Section 5 of the proposal.
3. Flat builds may keep a more direct HCI path (btdev callback) for low-end
IoT chips. We see no conflict with that; it can be an option next to the
socket model.
4. Kconfig: CONFIG_ZBLUE_ENABLED as the top-level switch, with CONFIG_BT_*
for the feature options, as agreed with Alan, is fine with us.
Open point 1: fork vs. staying in sync with Zephyr
You are right that the port layer needs NuttX kernel-style primitives
today, and that the compatibility layer has a cost. In flat build we use
some internal primitives; making the port layer use only public interfaces
is part of the protected/kernel work.
Our suggestion is to fork only where the NuttX architecture requires it,
not by default:
- The layers that move into the kernel (HCI core, connection management,
L2CAP, socket integration) become NuttX-maintained code. Those are the
parts that must be adapted to NuttX networking, memory management and
build modes anyway.
- The layers above (profiles, GATT services, LE Audio, Mesh, Classic
profiles) only depend on the Zephyr Bluetooth host API, not on the Zephyr
kernel. That is also where most upstream development and security fixes
happen. Keeping them close to upstream lets NuttX keep picking those
fixes up with little effort.
This way the compatibility layer shrinks over time instead of growing, and
the divergence happens step by step, where it brings real value.
Open point 2: external repository vs. in-tree
We suggest starting with an external git repository, fetched at a pinned
revision like NimBLE. This keeps the first patches small and easy to
review,
and gives everyone a working stack to test against from the start. The
kernel part will live in nuttx.git. Once the userspace part only contains
the layers above L2CAP, we can move it into nuttx-apps.git if the community
prefers that.
Proposed order of work:
1. Integrate the stack into nuttx-apps as an external git repository, as
described in the proposal.
2. Move the L2CAP layer and below into the NuttX kernel, replacing the
current kernel Bluetooth implementation (wireless/bluetooth and
net/bluetooth). The new kernel part must keep the existing functionality
and add BR/EDR Classic support.
3. Change the stack in nuttx-apps to drop its own L2CAP-and-below layers
and
use the NuttX kernel instead (sockets for protected/kernel builds; for
flat builds, optionally a direct function-call/callback path to the
kernel L2CAP layer). If needed at this step, the remaining
Zephyr-derived
code can be moved into nuttx-apps.git.
Each step is a separate series of small patches, and the stack keeps
working
after every step.
I would like to hear what Xiang, Alan, raiden00pl and others think about
this order and the two points above.
Proposed next step: once this is settled, we write a short joint roadmap
(owners and schedule for each step), post it here for review, and then
start with small, reviewable patches.
Thanks again for the open discussion.
Best regards,
Kai Cheng
________________________________
From: archer ***@***.***>
Sent: Wednesday, October 28, 2026 9:21:58 PM
To: apache/nuttx
Cc: 成凯; Mention
Subject: [External Mail]Re: [apache/nuttx] net/bt: Add native Bluetooth host
stack (PR #20686)
[外部邮件] ***@***.***进行反馈
[https://avatars.githubusercontent.com/u/758493?s=20&v=4]anchao left a
comment
(apache/nuttx#20686)<https://github.com/apache/nuttx/pull/20686#issuecomment-6470102813>
hi all We posted a proposal for integrating a Zephyr-based Bluetooth host as
a userspace stack in nuttx-apps (with an optional step-by-step path to a
BlueZ/Linux-style split) to dev@
https://lists.apache.org/thread.html/c6pl46o5l1ngb2zb3qtotq38o30h6v4b
Feedback welcome.
thanks
@chengkai15<https://github.com/chengkai15>
Thanks @chengkai15<https://github.com/chengkai15> , this is a good start. I
agree we should move the detailed
architecture discussion to dev@ and try to converge on one common direction
for
the Zephyr-based Bluetooth host instead of maintaining two separate
solutions.
I have replied in the mailing list with my concerns and suggestions,
especially
around the long-term sync model, whether zblue should be treated as a
NuttX-maintained fork or an always-rebased Zephyr subtree, and the desired
kernel/userspace split for Flat vs Protected/Kernel builds.
I am happy to work with you and the community to align on a common roadmap.
―
Reply to this email directly, view it on
GitHub<https://github.com/apache/nuttx/pull/20686?email_source=notifications&email_token=ABDILOM3CPHBGJE6GC2UGVL5WHXHNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBXGAYTAMRYGEZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6470102813>,
or
unsubscribe<https://github.com/notifications/unsubscribe-auth/ABDILONWQGLYF4LZ6SQF3BD5WHXHNAVCNFSNUABFKJSXA33TNF2G64TZHMZDEOBRGAZTENZTHNEXG43VMU5TKOBWG4ZTIMBYG4Z2C5QC>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
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!******/#
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
