You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by chao an <ma...@gmail.com> on 2026/10/16 03:25:01 UTC
PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Hi all,
I would like to summarize the background, technical motivation, and
proposed evolution plan for PR #20686, which introduces a Zephyr-based
Bluetooth host stack under net/bt.
https://github.com/apache/nuttx/pull/20686
First of all, I fully understand the concerns raised in the discussion.
Adding a new Bluetooth stack is a significant architectural change, and it
is reasonable for the community to ask whether we should instead continue
improving the existing NuttX Bluetooth implementation. I would like to
explain why we believe introducing the new stack incrementally is the more
practical path, while still keeping the long-term NuttX architecture clean
and maintainable.
------------------------------
1. Why not only enhance the existing NuttX Bluetooth stack?
The existing NuttX Bluetooth implementation is mainly focused on BLE
functionality. However, modern Bluetooth support is no longer limited to
basic BLE. A complete Bluetooth host stack now commonly includes:
- BLE GAP/GATT/ATT/SMP
- Classic Bluetooth profiles
- A2DP
- AVRCP
- HFP/HSP
- HID
- LE Mesh
- LE Audio
- Additional profile-level interoperability logic
The Zephyr Bluetooth stack already provides a broad and actively maintained
implementation across many of these areas. Rebuilding equivalent
functionality directly on top of the current NuttX Bluetooth stack would
require a very large multi-year effort, including not only protocol
implementation but also interoperability testing with real phones,
headsets, speakers, cars, and other commercial devices.
Therefore, our goal is not to discard NuttX's existing work lightly, but to
provide a practical path to make NuttX capable of supporting a much wider
Bluetooth feature set in a reasonable time frame.
------------------------------
2. Why place the stack in nuttx instead of nuttx-apps?
Another important discussion point is whether the new Bluetooth stack
should live in nuttx-apps, similar to how NimBLE is currently integrated.
Our concern is that a host stack is not just an application-level
component. It interacts closely with:
- HCI transport
- L2CAP channels
- Socket or device interfaces
- Memory pools
- Timers and work queues
- Security and pairing state
- Profile registration
- Controller event dispatch
- Future kernel/user boundary mechanisms
Putting the core host stack in nuttx-apps would either require exposing
many internal kernel interfaces or would force the application-side stack
to depend on non-public NuttX internals.
We already have a similar problem with the current NimBLE integration. The
NimBLE port in nuttx-apps directly depends on many NuttX kernel/internal
APIs. As a result, it is difficult to support protected/kernel builds
cleanly, and it is also hard to keep the port synchronized with upstream
NimBLE over time.
For this reason, we believe the Bluetooth host core belongs in the NuttX
tree. User-facing profiles, tools, shell commands, or demo applications can
still live outside the core as appropriate, but the transport-facing host
stack should have a well-defined place inside NuttX.
There is also a performance consideration. In flat build mode, the
Bluetooth host stack can run directly on the kernel side without additional
syscall or user/kernel boundary overhead. This is especially important for
IoT chips with relatively low CPU frequency, where Bluetooth data path and
profile handling overhead can have a visible impact on throughput, latency,
and power consumption.
At the same time, this does not mean that the final architecture must
remain flat-build-only. A compatible evolution path is to keep the
performance-sensitive transport and host core on the kernel side, while
gradually moving suitable Bluetooth profile implementations or
profile-facing helper layers into libc-visible build paths. This allows
protected and kernel builds to use proper public interfaces, while still
preserving good performance for flat build and low-end IoT platforms.
In other words, placing the stack in nuttx gives us a cleaner long-term
architecture:
- Flat build can get the best performance with minimum overhead.
- Protected/kernel build can be supported later through proper public
interfaces.
- Profile code can be migrated into libc-compatible paths where
appropriate.
- Userspace does not need to directly depend on private kernel symbols.
- The design avoids repeating the long-term maintainability issue seen
in some existing userspace Bluetooth integrations.
------------------------------
3. Coexistence with the existing NuttX Bluetooth stack
We also understand the concern that net/bt and the existing Bluetooth
implementation currently expose different APIs and are not mutually
compatible.
The current proposal is not to immediately remove the legacy stack.
Instead, the new stack is introduced as an optional implementation guarded
by Kconfig. This allows:
- Existing users of the legacy stack to continue working.
- New users to test the Zephyr-based stack.
- The community to compare functionality and architecture.
- Migration work to happen incrementally.
In the long term, if the new stack becomes stable and covers more use
cases, we can discuss how to reduce duplication, unify public APIs where
possible, or eventually deprecate parts that are no longer maintained. But
we do not propose an immediate disruptive replacement.
------------------------------
4. Current limitation: flat build only
The current implementation is intentionally limited to flat build.
This is now reflected in Kconfig by making CONFIG_BT depend on BUILD_FLAT.
The Kconfig help text also documents that protected and kernel builds are
not supported yet.
The reason is that the first phase focuses on getting the host stack
working correctly inside NuttX with minimal syscall overhead and minimal
boundary complexity. In flat build, the Bluetooth stack can run directly
with the required kernel-side resources, which is suitable for validating
the transport, host, and profile behavior first.
This also provides better runtime performance for low-end IoT chips, where
avoiding additional syscall and user/kernel boundary overhead is valuable
for Bluetooth throughput, latency, and power efficiency.
We do not want to hide this limitation. Protected/kernel build support is
important, but it should be added with a proper architecture rather than by
exposing many internal kernel APIs directly to userspace.
------------------------------
5. Planned protected/kernel build support
Our plan is to add protected/kernel build support in a later phase,
currently targeted for 27Q2.
The intended direction is:
- Keep the transport-facing Bluetooth host logic on the kernel side.
- Expose user-facing functionality through proper socket/VFS/device
interfaces.
- Move suitable profiles or profile helpers into libc-visible build
paths where appropriate.
- Allow profile implementations to be shared across flat, protected, and
kernel builds where possible.
- Avoid userspace directly depending on private kernel symbols.
- Keep syscall boundaries explicit and maintainable.
This is different from simply placing the whole host stack in nuttx-apps
and allowing it to call internal kernel APIs. We want to avoid repeating
the long-term maintainability problem that exists in some current userspace
Bluetooth integrations.
The goal is to support protected/kernel builds without sacrificing the
performance advantage that flat build can provide on resource-constrained
IoT platforms.
------------------------------
6. Why incremental upstreaming is useful
We understand the preference for a complete architecture before merging.
However, the Bluetooth stack is large. Waiting until BLE, Classic
Bluetooth, all profiles, socket integration, protected build support, and
every cleanup item are complete before upstreaming would make the patch set
very large and difficult to review.
An incremental approach has several advantages:
- The community can review the basic architecture earlier.
- Simulator testing can be added and improved gradually.
- BLE and Classic paths can be validated step by step.
- Future profile work can build on a shared base.
- Long-lived out-of-tree divergence can be avoided.
- Copyright and style issues can be corrected early.
- Architectural feedback can be incorporated before the stack grows
further.
This PR is intended as phase 1: establish the base host stack integration,
Kconfig structure, compatibility layer, and simulator-testable
functionality. It is not intended to claim that all final architecture work
is complete.
------------------------------
7. Testing status
At this stage, the supported platform is the simulator configuration only.
The simulator Bluetooth test framework covers both:
- Classic Bluetooth related paths.
- BLE related paths.
This allows us to validate the core host stack behavior in CI-friendly
environments first. Hardware-specific controller and transport support can
then be added progressively after the base stack becomes stable.
------------------------------
8. Copyright cleanup
The copyright concern is valid.
The imported code should preserve the original Zephyr copyright and license
information where applicable, and new NuttX-specific adaptation code should
follow the standard Apache NuttX copyright style.
Any unrelated third-party company copyright notices introduced by the
porting process should be removed unless they are legally required for
genuinely original contributions from that entity.
We are willing to clean this up as part of the PR.
------------------------------
9. Summary
To summarize our position:
- Enhancing the existing BLE-focused NuttX stack into a full modern
Bluetooth stack would be a very large effort.
- The Zephyr Bluetooth stack already provides broad functionality across
BLE, Classic Bluetooth, Mesh, LE Audio, and profiles.
- The new stack currently supports flat build only, and this limitation
is now explicitly documented in Kconfig.
- Flat build provides better runtime performance by avoiding additional
syscall and user/kernel boundary overhead, which is especially important
for low-end IoT chips.
- Protected/kernel build support is planned for 27Q2 using proper
socket/VFS/libc-visible interfaces instead of exposing private kernel APIs
directly.
- Suitable Bluetooth profile implementations can later be migrated into
libc-compatible build paths, allowing protected/kernel build compatibility
while preserving good performance in flat build.
- The new stack can coexist with the legacy Bluetooth implementation
during the transition period.
- Incremental upstreaming is preferable to maintaining a large
out-of-tree port until every future phase is complete.
- Simulator testing currently covers both Classic Bluetooth and BLE
paths.
We hope this clarifies the motivation and direction of the proposal. We are
open to improving the structure, naming, Kconfig organization, copyright
cleanup, and documentation based on community feedback. Our goal is to
provide NuttX with a maintainable path toward a complete modern Bluetooth
stack while respecting NuttX's architecture and long-term maintainability.
Thanks,
Archer
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi raiden00pl,
Because the protocol stack itself hasn't undergone structural changes. What
we've done so far is essentially kernel API replacement and code style
adjustments — adapting the Zephyr stack to NuttX's kernel interfaces. The
basic profiles (A2DP, BLE) are functional and working correctly at this
stage.
Keeping this on master has a practical purpose: it lowers the barrier for
other companies to see the work, test it, and contribute. This is exactly
the model that works in the Zephyr ecosystem — NXP, Nordic, Xiaomi, and
others all co-maintain the Bluetooth subsystem on the main branch. If we
isolate this on a separate branch, two things happen:
1. Nobody guarantees long-term maintenance. A side branch inevitably
falls behind as master moves forward, and the burden of rebasing and
keeping it alive falls on whoever initially pushed it. That's not
sustainable.
2. Companies and individual developers lose visibility. They won't track
a side branch for information sync, won't test it against their hardware,
and won't contribute back. The work becomes invisible and eventually
bitrots.
The goal here is to build a collaborative maintenance community around this
code, not a throwaway prototype. That only works if the code lives where
everyone can see it — on master.
raiden00pl <ra...@gmail.com> 于2026年10月16日周五 15:13写道：
> On another note, if this is a work-in-progress (WIP), why not create a
> separate
> branch in the upstream repository where this stack could be developed, and
> then
> merge it to master once it reaches a more mature stage?
> This would keep the work public without adding unfinished code to the
> master branch.
> I recall that this approach was used previously for some of the
> larger-scale, not finished changes.
>
> pt., 16 paź 2026 o 09:07 Xiang Xiao <xi...@gmail.com>
> napisał(a):
>
> > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> >
> > > Hi raiden00pl,
> > >
> > > Regarding your point about the NimBLE port using the POSIX API — yes,
> it
> > > uses POSIX, but there are real issues with the current implementation
> > that
> > > go beyond just kernel/protected mode support.
> > > 1. ble_npl_hw_enter_critical is not a real critical section
> > >
> > > Look at the NuttX port's implementation:
> > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > >
> > > static pthread_mutex_t s_mutex =
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > >
> > > uint32_t ble_npl_hw_enter_critical(void)
> > > {
> > > pthread_mutex_lock(&s_mutex);
> > > return 0;
> > > }
> > >
> > > This is a mutex, not a critical section. It does not disable interrupts
> > or
> > > preemption — an ISR can still fire and corrupt data that the "critical
> > > section" was supposed to protect. On top of that, using a mutex opens
> the
> > > door to ABBA deadlocks when combined with any other lock held inside
> the
> > > critical region:
> > >
> > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > blocked
> > > by B
> > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> > >
> > > Compare this with the FreeRTOS port, which correctly uses
> > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > scheduling/preemption). The current NuttX port simply does not meet the
> > > semantic contract that the NimBLE stack expects from
> > > ble_npl_hw_enter_critical.
> > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > >
> > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > >
> > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > which
> > > involves a syscall and floating-point arithmetic on every call. In a
> BLE
> > > stack where timestamps and timing are on the hot path, this adds
> > measurable
> > > overhead compared to accessing the kernel tick counter directly.
> > > 3. Others are already using the kernel approach — and for good reason
> > >
> > > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> > > uses kernel APIs directly, bypassing POSIX for the performance-critical
> > > paths:
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > >
> > > This isn't an academic exercise — it's a production choice. They
> > recognized
> > > that a BLE stack needs tight integration with the OS timer subsystem,
> > > direct access to critical section primitives, and efficient event
> > delivery,
> > > none of which POSIX provides well in this context.
> > > My question
> > >
> > > If other organizations are already using a more performant,
> > architecturally
> > > correct kernel-level integration for their BLE stacks on NuttX, why
> > should
> > > we be told that we must use the slower, less correct POSIX path?
> NuttX's
> > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > shipping
> > > a BLE stack with a broken critical section primitive. There should be
> > room
> > > for both approaches, and the decision should be driven by technical
> > merit,
> > > not by treating POSIX as the only acceptable answer.
> > >
> > >
> > I don't object to moving the key bluetooth stack to kernel space like how
> > the current bluetooth stack is done,
> > what I object to is that the current state of
> > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > into kernel space.
> > If I low my quality bar, I have requested my teammate to upstream our
> > implementation:
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > since much work needs to be done before it can achieve the quality
> > upstream.
> > BTW, many zephyr class BT features are developed by my team and upstream
> to
> > Zeprhy community.
> > If considering the quality, our version is much better since:
> >
> > 1. Product on smart speaker last year
> > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > 3. Product on wear device by end of this year
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by raiden00pl <ra...@gmail.com>.
On another note, if this is a work-in-progress (WIP), why not create a
separate
branch in the upstream repository where this stack could be developed, and
then
merge it to master once it reaches a more mature stage?
This would keep the work public without adding unfinished code to the
master branch.
I recall that this approach was used previously for some of the
larger-scale, not finished changes.
pt., 16 paź 2026 o 09:07 Xiang Xiao <xi...@gmail.com> napisał(a):
> On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
>
> > Hi raiden00pl,
> >
> > Regarding your point about the NimBLE port using the POSIX API — yes, it
> > uses POSIX, but there are real issues with the current implementation
> that
> > go beyond just kernel/protected mode support.
> > 1. ble_npl_hw_enter_critical is not a real critical section
> >
> > Look at the NuttX port's implementation:
> >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> >
> > static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> >
> > uint32_t ble_npl_hw_enter_critical(void)
> > {
> > pthread_mutex_lock(&s_mutex);
> > return 0;
> > }
> >
> > This is a mutex, not a critical section. It does not disable interrupts
> or
> > preemption — an ISR can still fire and corrupt data that the "critical
> > section" was supposed to protect. On top of that, using a mutex opens the
> > door to ABBA deadlocks when combined with any other lock held inside the
> > critical region:
> >
> > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> blocked
> > by B
> > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> >
> > Compare this with the FreeRTOS port, which correctly uses
> > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > scheduling/preemption). The current NuttX port simply does not meet the
> > semantic contract that the NimBLE stack expects from
> > ble_npl_hw_enter_critical.
> > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> >
> >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> >
> > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> which
> > involves a syscall and floating-point arithmetic on every call. In a BLE
> > stack where timestamps and timing are on the hot path, this adds
> measurable
> > overhead compared to accessing the kernel tick counter directly.
> > 3. Others are already using the kernel approach — and for good reason
> >
> > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> > uses kernel APIs directly, bypassing POSIX for the performance-critical
> > paths:
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> >
> > This isn't an academic exercise — it's a production choice. They
> recognized
> > that a BLE stack needs tight integration with the OS timer subsystem,
> > direct access to critical section primitives, and efficient event
> delivery,
> > none of which POSIX provides well in this context.
> > My question
> >
> > If other organizations are already using a more performant,
> architecturally
> > correct kernel-level integration for their BLE stacks on NuttX, why
> should
> > we be told that we must use the slower, less correct POSIX path? NuttX's
> > POSIX compliance is valuable, but it shouldn't come at the cost of
> shipping
> > a BLE stack with a broken critical section primitive. There should be
> room
> > for both approaches, and the decision should be driven by technical
> merit,
> > not by treating POSIX as the only acceptable answer.
> >
> >
> I don't object to moving the key bluetooth stack to kernel space like how
> the current bluetooth stack is done,
> what I object to is that the current state of
> https://github.com/apache/nuttx/pull/20686 is far to move entirely
> into kernel space.
> If I low my quality bar, I have requested my teammate to upstream our
> implementation:
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> since much work needs to be done before it can achieve the quality
> upstream.
> BTW, many zephyr class BT features are developed by my team and upstream to
> Zeprhy community.
> If considering the quality, our version is much better since:
>
> 1. Product on smart speaker last year
> 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> 3. Product on wear device by end of this year
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alan, Tomek,
Thank you!
And thanks to everyone who provided suggestions, review comments, and
testing
help on this patch. The feedback was very helpful for cleaning up the
layout,
license handling, Kconfig organization, and build integration before merge.
I really appreciate all the guidance and support from the community.
BR,
Tomek CEDRO <to...@cedro.info> 于2026年10月23日周五 06:27写道：
> Thank you Anchao and Alan :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Thu, Oct 22, 2026 at 1:46 PM Alan C. Assis <ac...@gmail.com> wrote:
> >
> > Great, thank you very much Anchao!
> >
> > On Thu, Oct 22, 2026 at 10:36 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi Alan,
> > >
> > >
> > >
> > > Thanks for the suggestion and for offering to help with testing!
> > >
> > >
> > >
> > > I agree with your point. It is better to avoid introducing net/bt as an
> > >
> > > intermediate layout if we already know it will be moved later, since
> that
> > >
> > > would create unnecessary churn and could become a breaking change after
> > >
> > > merge.
> > >
> > >
> > >
> > > I have updated the patch accordingly:
> > >
> > >
> > >
> > > - Moved the Bluetooth host stack build integration out of net/
> > >
> > > - Kept the implementation under libs/zblue
> > >
> > > - Added libs/zblue as a standalone NuttX library, similar to other
> libs/*
> > >
> > > components
> > >
> > > - Moved the Kconfig entry under the top-level Wireless Support menu
> > >
> > > - Registered libzblue through the standard Make library target flow
> > >
> > > - Reworked the Make.defs paths to use TOPDIR-based paths instead of
> > > relative
> > > ../libs/zblue paths
> > >
> > >
> > >
> > > I also re-tested the integration with the sim:bt configuration, and the
> > > native
> > > Make build passes. I re-ran nxstyle and codespell as well, and both are
> > > clean.
> > >
> > >
> > > For the Kconfig selection, I agree that more explicit options will
> make it
> > >
> > > easier for users to enable only the parts they need. I will continue
> > > refining
> > > that so the stack is not exposed as one overly broad switch.
> > >
> > >
> > >
> > > Thanks again for the review and for working on the BT side too. Any
> > > additional
> > > testing from your side would be very welcome.
> > >
> > >
> > >
> > > BR,
> > >
> > >
> > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 20:28写道：
> > >
> > > > Hi Anchao,
> > > >
> > > > Sounds good!
> > > >
> > > > Yes, I suggest going with more explicitly selection in the Kconfig so
> > > users
> > > > can select what they want more easily.
> > > >
> > > > Regarding "net/bt," there is not a more permanent solution than a
> > > temporary
> > > > one. This is a reason to avoid it.
> > > >
> > > > I understand that you tested the integration this way and agreed to
> > > change
> > > > it to libs/zblue later, but I strongly recommend making that change
> > > before
> > > > merging.
> > > >
> > > > Adding something that will probably change will result in a "breaking
> > > > change" later, which we are trying to avoid on NuttX.
> > > >
> > > > So the best moment to change it is before it gets merged. If you need
> > > help
> > > > testing, I can assist here. I'm already working on BT (first fixing
> small
> > > > issues).
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Thu, Oct 22, 2026 at 8:55 AM chao an <ma...@gmail.com> wrote:
> > > >
> > > > > Hi Alan,
> > > > >
> > > > > Yes, I agree that we need to find a middle ground and make sure the
> > > > > integration does not block the existing Bluetooth solutions in
> NuttX.
> > > > >
> > > > > From the current implementation, I don't think this zblue-based
> stack
> > > > > conflicts with NimBLE or with the existing in-tree BLE stack. They
> can
> > > be
> > > > > selected independently through Kconfig. For example:
> > > > >
> > > > > - CONFIG_BT Enables the new zblue-based host stack currently
> added
> > > by
> > > > > this PR.
> > > > > - CONFIG_WIRELESS_BLUETOOTH
> > > > > - CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE
> stack
> > > > > under wireless/bluetooth.
> > > > > - CONFIG_NIMBLE Enables the userspace NimBLE stack when that
> stack
> > > is
> > > > > used from apps.
> > > > >
> > > > > The lower-level Bluetooth controller / transport drivers are also
> > > > separate,
> > > > > for example:
> > > > >
> > > > > - CONFIG_BLUETOOTH_UART
> > > > > - CONFIG_BLUETOOTH_RPMSG
> > > > > - CONFIG_BLUETOOTH_NULL
> > > > >
> > > > > So I think it is possible to make the three options coexist on
> NuttX,
> > > as
> > > > > long as we keep the host-stack selection separated and avoid
> enabling
> > > two
> > > > > host stacks for the same controller path at the same time. If
> needed,
> > > we
> > > > > can also make this more explicit by adding a Kconfig choice or
> mutual
> > > > > exclusion between the host stacks.
> > > > >
> > > > > Regarding the location, I understand your point about libs/zblue.
> > > > However,
> > > > > for the initial version, I still think keeping the full stack under
> > > > net/bt
> > > > > is the safer integration path.
> > > > >
> > > > > The reason is that splitting it into libs/zblue is not only a
> directory
> > > > > rename. To do that correctly, we need to isolate each profile and
> data
> > > > path
> > > > > according to its own characteristics. Some profiles are not just
> pure
> > > > > userspace library logic. For example, SCO and LE Audio / ISO have
> > > > > lower-level data paths. On Linux, part of this kind of traffic is
> > > handled
> > > > > or forwarded by the kernel side. So if we move everything to
> libs/zblue
> > > > too
> > > > > early, we may create an artificial boundary that is not correct for
> > > those
> > > > > lower-level profiles.
> > > > >
> > > > > My suggestion is:
> > > > >
> > > > > 1. Keep the initial version integrated under net/bt, so the
> > > > controller,
> > > > > HCI, L2CAP, ISO/SCO and profile paths can work correctly first.
> > > > > 2. Make the stack name clear as zblue if the community prefers
> that,
> > > > so
> > > > > it is not presented as replacing the existing NuttX BLE stack.
> > > > > 3. Keep the Kconfig separation so users can choose between:
> > > > > - zblue-based stack,
> > > > > - existing NuttX BLE stack,
> > > > > - NimBLE userspace stack.
> > > > > 4. After the initial integration is stable, we can evaluate
> moving
> > > or
> > > > > splitting parts into libs/zblue profile by profile, where the
> > > boundary
> > > > > is
> > > > > technically clear.
> > > > >
> > > > > So yes, I think it is possible to modify the PR to let both stacks
> plus
> > > > > NimBLE work on NuttX without interfering with each other. I just
> think
> > > > > doing a full libs/zblue separation as the first step may be risky,
> > > > > especially for the lower-level profiles and audio-related paths.
> > > > >
> > > > > Does this direction sound acceptable to you?
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 19:32写道：
> > > > >
> > > > > > Hi Anchao,
> > > > > >
> > > > > > Yes, I think having a complete BLE stack like zblue is a good
> idea.
> > > > > >
> > > > > > But we need to find a middle ground for correct integration.
> > > > > >
> > > > > > Let's do this: add zblue to libs/zglue and maintain a proper
> > > separation
> > > > > to
> > > > > > allow room for the existing BLE stack on NuttX to evolve.
> > > > > >
> > > > > > Just assuming that not updating/synchroning zblue with Zephyr's
> zblue
> > > > > will
> > > > > > be enough for them to become different entities seems incorrect.
> > > > > >
> > > > > > The amount of code is very large, so even after decades they will
> > > share
> > > > > > enough of their "DNA" that a virus will be able to infect both.
> > > > > >
> > > > > > Do you think it is possible to modify your PR to let both stacks
> (+
> > > > > NimBLE
> > > > > > userspace stack) work on NuttX without one interfering on the
> other?
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > > On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi Alan,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thank you for the detailed analysis.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I understand your concern. The current code structure is indeed
> > > still
> > > > > > very
> > > > > > >
> > > > > > > close to Zephyr's Bluetooth stack, and the compatibility layer
> is
> > > > > > currently
> > > > > > >
> > > > > > > quite thin. However, from the long-term technical direction,
> our
> > > > > > intention
> > > > > > > is
> > > > > > > not to keep doing long-term synchronization with Zephyr.
> Instead,
> > > we
> > > > > plan
> > > > > > > to
> > > > > > > quickly feed back the related issues and improvements to the
> NuttX
> > > > > > > community
> > > > > > > during the integration and evolution process.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Regarding the naming concern, I think it is reasonable to call
> it
> > > > zblue
> > > > > > >
> > > > > > > temporarily, since the current implementation is still largely
> > > based
> > > > on
> > > > > > >
> > > > > > > Zephyr's Bluetooth stack. If the stack evolves later with a new
> > > code
> > > > > > > structure
> > > > > > > and clearer NuttX-specific architecture, we can further
> evaluate
> > > > > whether
> > > > > > a
> > > > > > >
> > > > > > > different name would be more appropriate at that time.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Does that sound reasonable to you?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > BR,
> > > > > > >
> > > > > > >
> > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> > > > > > >
> > > > > > > > Hi Anchao,
> > > > > > > >
> > > > > > > > I used Claude to help compare the code and here are the
> reasons
> > > to
> > > > > call
> > > > > > > it
> > > > > > > > zblue instead of libs/bt:
> > > > > > > >
> > > > > > > > Almost all of this PR is Zephyr's Bluetooth stack
> > > > > > > > ("zblue"), reformatted to NuttX style. The part that doesn't
> come
> > > > > from
> > > > > > > > Zephyr is
> > > > > > > > a thin compatibility layer that makes the Zephyr kernel calls
> > > work
> > > > on
> > > > > > > > NuttX.
> > > > > > > >
> > > > > > > > I pulled all 539 new files (400,450 lines) and compared them
> > > > against
> > > > > > > > several
> > > > > > > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and
> it
> > > > > matches
> > > > > > > > better
> > > > > > > > than Zephyr's current main branch. So the PR looks like a
> > > snapshot
> > > > of
> > > > > > > zblue
> > > > > > > > from the last few weeks.
> > > > > > > >
> > > > > > > > Results
> > > > > > > >
> > > > > > > > Function by function (7,716 functions):
> > > > > > > >
> > > > > > > > Class: Identical
> > > > > > > > Functions: 5,411 (70%)
> > > > > > > > Lines: 140,189
> > > > > > > > Meaning: Exactly the same code as Zephyr. Only indentation
> and
> > > > > braces
> > > > > > > > differ.
> > > > > > > > ────────────────────────────────────────
> > > > > > > > Class: Renames only
> > > > > > > > Functions: 1,515 (20%)
> > > > > > > > Lines: 60,863
> > > > > > > > Meaning: The only changes are API renames that recur
> across the
> > > > > whole
> > > > > > > PR:
> > > > > > > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> > > > > > > sys_slist_*→list_*,
> > > > > > > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post,
> > > > atomic_get→atomic_read
> > > > > > > > ────────────────────────────────────────
> > > > > > > > Class: Modified
> > > > > > > > Functions: 584 (8%)
> > > > > > > > Lines: 33,693
> > > > > > > > Meaning: Clearly the Zephyr function, plus some edits
> specific
> > > to
> > > > > > that
> > > > > > > > function
> > > > > > > > ────────────────────────────────────────
> > > > > > > > Class: Not from Zephyr
> > > > > > > > Functions: 206 (3%)
> > > > > > > > Lines: 2,734
> > > > > > > > Meaning: NuttX glue code
> > > > > > > >
> > > > > > > > Whole files, including headers:
> > > > > > > > - On average, 96.9% of each file's code also appears in its
> > > > Zephyr
> > > > > > > > counterpart.
> > > > > > > > - 434 of the 539 files are ≥90% the same as Zephyr;
> together
> > > they
> > > > > > hold
> > > > > > > > 375k of
> > > > > > > > the 400k lines.
> > > > > > > > - 75% of the comment text, including the Doxygen docs, is
> > > > > > word-for-word
> > > > > > > > Zephyr.
> > > > > > > >
> > > > > > > > What's actually new:
> > > > > > > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c,
> > > > > > mem_slab.c,
> > > > > > > > fs.c,
> > > > > > > > sections/defines.c, hci_driver.c), which provides k_work,
> > > > k_queue
> > > > > > and
> > > > > > > > similar
> > > > > > > > Zephyr calls on top of NuttX.
> > > > > > > > - Part of mm/net_buf.
> > > > > > > > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > > > > > > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt
> > > > defconfig.
> > > > > > > >
> > > > > > > >
> > > > > > > > So, only 3% of the code is new (this includes the code in
> sim:bt
> > > > that
> > > > > > > must
> > > > > > > > be new).
> > > > > > > >
> > > > > > > > So, reusing the zblue from Zephyr and calling it something
> else
> > > > isn't
> > > > > > > > right; it's like the zbus that Jorge brought from Zephyr,
> where
> > > > > calling
> > > > > > > it
> > > > > > > > NXBus doesn't seem appropriate.
> > > > > > > >
> > > > > > > > Besides that, as I said before using ZBlue as our official BT
> > > Stack
> > > > > > will
> > > > > > > > significantly increase the shared code between NuttX and
> Zephyr,
> > > > > which
> > > > > > > > could be dangerous.
> > > > > > > >
> > > > > > > > As I said, I not against adding ZBlue to NuttX, but at least
> make
> > > > it
> > > > > > > clear
> > > > > > > > that it is ZBlue and should be an alternative stack (like
> NimBLE)
> > > > not
> > > > > > the
> > > > > > > > official NuttX BLE Stack.
> > > > > > > >
> > > > > > > > BR,
> > > > > > > >
> > > > > > > > Alan
> > > > > > > >
> > > > > > > > On Mon, Oct 19, 2026 at 12:34 AM chao an <
> magicdcps@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Alan,
> > > > > > > > >
> > > > > > > > > Thanks for the comments and suggestions.
> > > > > > > > >
> > > > > > > > > For the first stage, I would prefer to keep the Bluetooth
> host
> > > > > stack
> > > > > > > > > supported only in FLAT mode. Supporting Protected and
> Kernel
> > > > modes
> > > > > > > > requires
> > > > > > > > > a much deeper rework of the stack and its interfaces,
> > > especially
> > > > > > around
> > > > > > > > the
> > > > > > > > > boundary between kernel space and user space. I do not
> think it
> > > > is
> > > > > a
> > > > > > > good
> > > > > > > > > idea to introduce such large architectural changes in this
> > > first
> > > > > > step.
> > > > > > > > >
> > > > > > > > > Our current plan is to complete Protected/Kernel mode
> support
> > > in
> > > > a
> > > > > > > second
> > > > > > > > > stage, after the basic stack integration is reviewed and
> > > > > stabilized.
> > > > > > > This
> > > > > > > > > should make the initial review and integration much more
> > > > > manageable.
> > > > > > > > >
> > > > > > > > > Regarding the library name, I still prefer to use
> libs/libbt.
> > > > > > Although
> > > > > > > > the
> > > > > > > > > current code is based on Zephyr's zblue, the goal is to
> > > maintain
> > > > it
> > > > > > as
> > > > > > > an
> > > > > > > > > independent NuttX Bluetooth host stack going forward,
> rather
> > > than
> > > > > > > keeping
> > > > > > > > > it as a direct Zephyr fork forever. In that sense, I think
> > > libbt
> > > > > is a
> > > > > > > > > better long-term name.
> > > > > > > > >
> > > > > > > > > Also, the current NuttX Bluetooth profiles are not
> implemented
> > > in
> > > > > the
> > > > > > > > > kernel, and we do not plan to move the native NuttX
> Bluetooth
> > > > stack
> > > > > > > > > profiles into the kernel either. Once Protected/Kernel mode
> > > > support
> > > > > > is
> > > > > > > > > added for this stack in the future, this implementation is
> > > > expected
> > > > > > to
> > > > > > > > > replace the previous approach. For this reason, I think
> keeping
> > > > the
> > > > > > > stack
> > > > > > > > > under libbt is still more appropriate.
> > > > > > > > >
> > > > > > > > > About splitting the PR: this PR is already the result of
> > > > squashing
> > > > > > more
> > > > > > > > > than one hundred commits. Most of those commits are
> > > > > > compatibility-layer
> > > > > > > > > adjustments, coding style cleanup, and mechanical changes
> > > needed
> > > > to
> > > > > > > make
> > > > > > > > > the stack build in NuttX. Asking reviewers to review each
> of
> > > > those
> > > > > > > > commits
> > > > > > > > > separately would probably cost everyone more time.
> > > > > > > > >
> > > > > > > > > Splitting the full Bluetooth stack by profile is also not
> very
> > > > > > > practical
> > > > > > > > at
> > > > > > > > > the moment, because there are no dedicated maintainers for
> each
> > > > > > > > individual
> > > > > > > > > Bluetooth profile area in NuttX yet. Therefore, I think the
> > > > current
> > > > > > > form
> > > > > > > > is
> > > > > > > > > probably the most reasonable way to review and integrate
> the
> > > > stack
> > > > > > as a
> > > > > > > > > whole.
> > > > > > > > >
> > > > > > > > > One more update: I have removed all shell-related code from
> > > > > > > > > https://github.com/apache/nuttx/pull/20686. The plan is to
> > > move
> > > > > > those
> > > > > > > > > shell
> > > > > > > > > commands to apps later. With this change, the current
> Bluetooth
> > > > > stack
> > > > > > > no
> > > > > > > > > longer contains any user-space shell code, so I think this
> is
> > > > now a
> > > > > > > > better
> > > > > > > > > point for review.
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > > > > > > > >
> > > > > > > > > > Hi An Chao,
> > > > > > > > > >
> > > > > > > > > > Isn't it possible to have a similar implementation that
> works
> > > > for
> > > > > > > FLAT,
> > > > > > > > > > Protected and Kernel modes?
> > > > > > > > > >
> > > > > > > > > > This way the maintenance will be easier. Only small
> > > > > kernel-specific
> > > > > > > > parts
> > > > > > > > > > will remain there (as Raiden and Xiang proposed).
> > > > > > > > > >
> > > > > > > > > > Suggestion: instead of naming it libs/libbt/, it would be
> > > > better
> > > > > to
> > > > > > > use
> > > > > > > > > > libs/zblue to make it clear that it is a zblue port from
> > > > Zephyr.
> > > > > > > > > >
> > > > > > > > > > Let's use libs/libbt only for NuttX-specific (native)
> code.
> > > > > > > > > >
> > > > > > > > > > And as I said, it is better to easily isolate the code
> that
> > > > came
> > > > > > from
> > > > > > > > > > Zephyr's zblue.
> > > > > > > > > >
> > > > > > > > > > This way the user could select the Bluetooth stack they
> want
> > > > > > without
> > > > > > > > > having
> > > > > > > > > > code from the other stack attached to it.
> > > > > > > > > >
> > > > > > > > > > Also I suggest you to break your PR into smaller PRs; a
> > > single
> > > > PR
> > > > > > > > > changing
> > > > > > > > > > more than 660K LoC is very massive.
> > > > > > > > > >
> > > > > > > > > > BR,
> > > > > > > > > >
> > > > > > > > > > Alan
> > > > > > > > > >
> > > > > > > > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <
> magicdcps@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Alan,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for the thoughtful perspective and for
> engaging
> > > in
> > > > > the
> > > > > > > > > > > discussion.
> > > > > > > > > > >
> > > > > > > > > > > On security: we will maintain the Bluetooth stack
> ourselves
> > > > and
> > > > > > > take
> > > > > > > > > > > responsibility for tracking and fixing
> vulnerabilities. I'm
> > > > > also
> > > > > > > > > > confident
> > > > > > > > > > > that Xiaomi will contribute back on security issues
> given
> > > > their
> > > > > > > > ongoing
> > > > > > > > > > > investment in this codebase. This isn't a blind import
> —
> > > it's
> > > > > > code
> > > > > > > > that
> > > > > > > > > > has
> > > > > > > > > > > active, committed maintainers behind it.
> > > > > > > > > > >
> > > > > > > > > > > Regarding the history with Greg: you're right that we
> > > > discussed
> > > > > > > this
> > > > > > > > > > years
> > > > > > > > > > > ago. But there's an important distinction — that
> earlier
> > > > > proposal
> > > > > > > > > placed
> > > > > > > > > > > the stack entirely in userspace. It did nothing to
> > > strengthen
> > > > > > > NuttX's
> > > > > > > > > > > kernel-level Bluetooth support. That's precisely why
> I'm
> > > back
> > > > > > now,
> > > > > > > > > > > providing a kernel implementation this time around,
> which
> > > is
> > > > > > what I
> > > > > > > > > > > committed to back then. Feel free to search the mailing
> > > list
> > > > > > > > archives —
> > > > > > > > > > the
> > > > > > > > > > > NuttX native Bluetooth stack will evolve from this
> baseline
> > > > > going
> > > > > > > > > > forward.
> > > > > > > > > > >
> > > > > > > > > > > This implementation does not affect existing Bluetooth
> > > stacks
> > > > > in
> > > > > > > any
> > > > > > > > > way.
> > > > > > > > > > > Users can still choose NimBLE, the current NuttX BLE
> stack,
> > > > or
> > > > > > any
> > > > > > > > > other
> > > > > > > > > > > solution. This is an additional option, not a
> replacement.
> > > > The
> > > > > > goal
> > > > > > > > is
> > > > > > > > > to
> > > > > > > > > > > give NuttX users more choices, not fewer.
> > > > > > > > > > >
> > > > > > > > > > > One more update: I just spoke with Xiaoxiang and we've
> > > > reached
> > > > > > some
> > > > > > > > > > common
> > > > > > > > > > > ground. He's no longer opposed to the current stack
> > > > > > implementation
> > > > > > > > and
> > > > > > > > > > > agrees that the focus should be on proper structuring.
> > > Here's
> > > > > the
> > > > > > > > plan
> > > > > > > > > > > going forward:
> > > > > > > > > > >
> > > > > > > > > > > 1. Unused shell code will be moved out of the stack
> and
> > > > into
> > > > > > > > apps/,
> > > > > > > > > > > running entirely in userspace.
> > > > > > > > > > > 2. Bluetooth profiles will be migrated to
> libs/libbt/,
> > > > where
> > > > > > > we'll
> > > > > > > > > > > provide two OS API backends: a POSIX API
> implementation
> > > > (for
> > > > > > > > > > > kernel/protected builds) and a NuttX kernel API
> > > > > implementation
> > > > > > > > (for
> > > > > > > > > > flat
> > > > > > > > > > > mode).
> > > > > > > > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > > > > > > > >
> > > > > > > > > > > This should address the architectural concerns while
> > > > preserving
> > > > > > the
> > > > > > > > > > > performance path for flat-mode deployments.
> > > > > > > > > > >
> > > > > > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五
> 18:40写道：
> > > > > > > > > > >
> > > > > > > > > > > > Hi An Chao,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for trying to improve the NuttX Bluetooth
> > > > support.
> > > > > > And
> > > > > > > > > thank
> > > > > > > > > > > you
> > > > > > > > > > > > to bring this discussion here to let more people give
> > > their
> > > > > > > > opinion.
> > > > > > > > > > > >
> > > > > > > > > > > > I think most of the concerns raised by Xiang and
> Raiden
> > > > > > (Mateusz)
> > > > > > > > are
> > > > > > > > > > > > important and need to be addressed.
> > > > > > > > > > > >
> > > > > > > > > > > > As I said at GitHub PR I think a main concern here is
> > > using
> > > > > the
> > > > > > > > same
> > > > > > > > > > > > Bluetooth stack used on Zephyr, not because it is a
> bad
> > > > stack
> > > > > > (of
> > > > > > > > > > course
> > > > > > > > > > > it
> > > > > > > > > > > > is not, it was developed by experts on Bluetooth
> area),
> > > but
> > > > > > > because
> > > > > > > > > we
> > > > > > > > > > > are
> > > > > > > > > > > > adding the same surface area of attack from Zephyr on
> > > > NuttX.
> > > > > > > > > > > >
> > > > > > > > > > > > That means any security vulnerability affecting
> Zephyr
> > > BLE
> > > > > > stack
> > > > > > > > will
> > > > > > > > > > > > affect NuttX. It remove the protection that a
> companies
> > > > could
> > > > > > > > obtain
> > > > > > > > > > when
> > > > > > > > > > > > using different RTOSs.
> > > > > > > > > > > >
> > > > > > > > > > > > Also, if my memory still serving me, I think Xiaomi
> team
> > > > (you
> > > > > > was
> > > > > > > > > there
> > > > > > > > > > > at
> > > > > > > > > > > > that time) already tried to submit their initial
> port of
> > > > > Zephyr
> > > > > > > BLE
> > > > > > > > > > stack
> > > > > > > > > > > > to NuttX about 4 or 5 years ago and Greg was against
> it.
> > > > > > > > > > > >
> > > > > > > > > > > > His suggestion was to improve our BLE stack, that in
> fact
> > > > has
> > > > > > the
> > > > > > > > > same
> > > > > > > > > > > > origin of the Zephyr BLE stack (both came from a BLE
> > > stack
> > > > > from
> > > > > > > > Intel
> > > > > > > > > > > > released as BSD license at that time).
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not against including the Zephyr BLE stack, but
> it
> > > > should
> > > > > > be
> > > > > > > > > > > > selectable. Ideally the user should select if he/she
> > > wants
> > > > to
> > > > > > use
> > > > > > > > > > NimBLE,
> > > > > > > > > > > > Zephyr or NuttX native BLE stack.
> > > > > > > > > > > >
> > > > > > > > > > > > BR,
> > > > > > > > > > > >
> > > > > > > > > > > > Alan
> > > > > > > > > > > >
> > > > > > > > > > > > On Friday, October 16, 2026, chao an <
> > > magicdcps@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi, Tomek,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for the thoughtful input and the FreeBSD
> > > > references
> > > > > —
> > > > > > > > those
> > > > > > > > > > are
> > > > > > > > > > > > very
> > > > > > > > > > > > > relevant to where we're heading.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just to set the context: NuttX's current Bluetooth
> > > stack
> > > > > only
> > > > > > > > > > supports
> > > > > > > > > > > > BLE.
> > > > > > > > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio
> are
> > > all
> > > > > > > > missing.
> > > > > > > > > > This
> > > > > > > > > > > > is
> > > > > > > > > > > > > exactly why we want to bring a more complete
> Bluetooth
> > > > > stack
> > > > > > to
> > > > > > > > > > NuttX —
> > > > > > > > > > > > to
> > > > > > > > > > > > > catch up with what mainstream RTOS communities
> already
> > > > > offer.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I actually agree with the FreeBSD/Apple
> architecture
> > > you
> > > > > > > > > referenced.
> > > > > > > > > > > Our
> > > > > > > > > > > > > end-state plan is similar: the L2CAP and HCI layers
> > > will
> > > > > live
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > > > kernel, and a bluetoothd-style daemon will be
> > > implemented
> > > > > in
> > > > > > > > libc,
> > > > > > > > > > > > managing
> > > > > > > > > > > > > profiles and higher-level protocols. This gives us
> a
> > > > clean
> > > > > > > > > > separation —
> > > > > > > > > > > > > transport in the kernel, policy and profiles in
> > > > userspace —
> > > > > > > much
> > > > > > > > > like
> > > > > > > > > > > how
> > > > > > > > > > > > > FreeBSD's ng_hci / hccontrol split works. The
> current
> > > PR
> > > > is
> > > > > > > > Phase 1
> > > > > > > > > > of
> > > > > > > > > > > > > getting there incrementally.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五
> 17:07写道：
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Thank you An Chao for this proposition, work, and
> > > > > > discussion
> > > > > > > > :-)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > For sure it would be nice to have a BT stack with
> > > more
> > > > > > > > features!
> > > > > > > > > > The
> > > > > > > > > > > > > > BT has known issue of having different
> > > implementations
> > > > of
> > > > > > the
> > > > > > > > > stack
> > > > > > > > > > > on
> > > > > > > > > > > > > > different RTOS / OS / platforms, which is a known
> > > > issue,
> > > > > > and
> > > > > > > > > kinda
> > > > > > > > > > > > > > mess because there is no common standard /
> approach /
> > > > > > > > > > implementation,
> > > > > > > > > > > > > > unfortunately around something that is supposed
> to be
> > > > > based
> > > > > > > on
> > > > > > > > a
> > > > > > > > > > > > > > common standard.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Having common BT stack with other popular RTOS
> may
> > > make
> > > > > > > > > portability
> > > > > > > > > > > > > > easier and developers move to NuttX in some
> cases.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I understand that we are talking about this
> solution?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > > > > > > > connectivity/bluetooth/index.html
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > In a perfect situation we would want to have
> modular
> > > > > > > > > implementation
> > > > > > > > > > > in
> > > > > > > > > > > > > > nuttx-apps just like nimble. This is pointed out
> by
> > > > > Xiang,
> > > > > > > > > Raiden,
> > > > > > > > > > > and
> > > > > > > > > > > > > > Alin already. But I understand some things may be
> > > hard
> > > > to
> > > > > > > > > implement
> > > > > > > > > > > > > > that way. I will follow the consensus here when
> > > ready,
> > > > I
> > > > > > have
> > > > > > > > no
> > > > > > > > > > > > > > strong opinion here, except any BT stack I
> touched
> > > > before
> > > > > > > was a
> > > > > > > > > > mess
> > > > > > > > > > > > > > and I hope we can work out at least something
> decent
> > > > :-P
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A bit offtopic but for kernel build we can take a
> > > look
> > > > at
> > > > > > > quite
> > > > > > > > > old
> > > > > > > > > > > > > > Bluetooth implementation on FreeBSD, where radio
> is
> > > > > > provided
> > > > > > > by
> > > > > > > > > > > ng_ubt
> > > > > > > > > > > > > > (lower half in out case), then upper half uses
> > > standard
> > > > > > HCI.
> > > > > > > > > Maybe
> > > > > > > > > > > > > > something like this is possible in NuttX?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1.
> > > https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > > > > > > > 2.
> https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > > > > > > > 3.
> > > https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > > > > > > > 4.
> > > > > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > > > > > > > 5.
> > > > > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > > > > > > > 6.
> https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Here is a quick overview article on the Bluetooth
> > > > > > > > implementation
> > > > > > > > > in
> > > > > > > > > > > > > > FreeBSD and Apple:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Again it will be very nice to have fully
> featured BT
> > > > > stack
> > > > > > in
> > > > > > > > > NuttX
> > > > > > > > > > > > > > and I hope we can sort out the best possible
> porting
> > > > > > > > > implementation
> > > > > > > > > > > > > > :-)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > > > > > > > jerpelea@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > thanks Xiao and Raiden for your technical
> opinions
> > > > > which
> > > > > > I
> > > > > > > > also
> > > > > > > > > > > share
> > > > > > > > > > > > > so
> > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > will not iterate them again.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > > > > > > > it should be splitted between nuttx and
> apps-repos
> > > > and
> > > > > > use
> > > > > > > > > POSIX
> > > > > > > > > > > > > > > implementation as much as possible. We are
> focused
> > > on
> > > > > > > > standards
> > > > > > > > > > and
> > > > > > > > > > > > > > > compatibility.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Another concern is the license which does not
> match
> > > > our
> > > > > > ASF
> > > > > > > > one
> > > > > > > > > > and
> > > > > > > > > > > > > does
> > > > > > > > > > > > > > > not include any LICENSE file additions to
> clarify
> > > the
> > > > > > > > compiance
> > > > > > > > > > > > aspect
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Best regards
> > > > > > > > > > > > > > > Alin J
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > > > > > > > xiaoxiang781216@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > > > > > > > magicdcps@gmail.com
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So the real reason you've been objecting
> to my
> > > > > > proposal
> > > > > > > > is
> > > > > > > > > > that
> > > > > > > > > > > > > your
> > > > > > > > > > > > > > team
> > > > > > > > > > > > > > > > > has been working on something similar,
> correct?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If you can give me a clear timeline for
> when
> > > your
> > > > > > > > > > > implementation
> > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > > submitted upstream, I'm happy to withdraw
> my PR
> > > > and
> > > > > > let
> > > > > > > > > your
> > > > > > > > > > > code
> > > > > > > > > > > > > > serve
> > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > the baseline. I'm not here to fight over
> > > > ownership
> > > > > of
> > > > > > > the
> > > > > > > > > > > > Bluetooth
> > > > > > > > > > > > > > > > stack.
> > > > > > > > > > > > > > > > > My only motivation is that NuttX's lack of
> a
> > > > > capable
> > > > > > > > > > Bluetooth
> > > > > > > > > > > > > stack
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > driving every developer toward Zephyr —
> and as
> > > a
> > > > > PMC
> > > > > > > > > member,
> > > > > > > > > > I
> > > > > > > > > > > > > think
> > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > should be asking yourselves why this gap
> has
> > > > > remained
> > > > > > > > > > unfilled
> > > > > > > > > > > > for
> > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > long.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I object to landing the whole bluetooth stack
> > > into
> > > > > > kernel
> > > > > > > > > space
> > > > > > > > > > > > > > directly
> > > > > > > > > > > > > > > > either yours and ours .
> > > > > > > > > > > > > > > > This is the same feeling from raiden00pl too,
> > > let's
> > > > > see
> > > > > > > > other
> > > > > > > > > > > > > people's
> > > > > > > > > > > > > > > > opinions here.
> > > > > > > > > > > > > > > > But it's fine for me to host the whole code
> in
> > > > > > > > nuttx-apps.git
> > > > > > > > > > and
> > > > > > > > > > > > > > refactor
> > > > > > > > > > > > > > > > components to kernel
> > > > > > > > > > > > > > > > space step by step.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As for the current PR, I'll remove the
> shell
> > > > > > components
> > > > > > > > > from
> > > > > > > > > > > the
> > > > > > > > > > > > > > stack
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > move them into apps/ where they belong. The
> > > base
> > > > > > > profiles
> > > > > > > > > > > (A2DP,
> > > > > > > > > > > > > BLE)
> > > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > > stay in libc —
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The architecture is wrong to host any
> bluetooth
> > > > > > profile
> > > > > > > in
> > > > > > > > > > libc.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > in flat build mode this gives a significant
> > > > > performance
> > > > > > > > > > > > > > > > > boost to the overall stack, which is the
> > > primary
> > > > > > > > deployment
> > > > > > > > > > > model
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > > NuttX devices.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Performance should remain the same whether
> the
> > > base
> > > > > > > profile
> > > > > > > > > is
> > > > > > > > > > > > hosted
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > libc or apps,
> > > > > > > > > > > > > > > > could you point out any technical reason
> which
> > > > > impacts
> > > > > > > the
> > > > > > > > > > > > > performance
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > the flat mode?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > A few additional data points regarding our
> > > > > timeline:
> > > > > > > our
> > > > > > > > > > > product
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > scheduled for release in December, and
> > > Bluetooth
> > > > > SIG
> > > > > > > > > > > > certification
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > already in progress — we expect to receive
> it
> > > > > around
> > > > > > > > > > November.
> > > > > > > > > > > If
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > baseline were to switch to your team's
> stack
> > > with
> > > > > its
> > > > > > > > > > different
> > > > > > > > > > > > > > > > > architecture, that certification cycle
> would
> > > need
> > > > > to
> > > > > > be
> > > > > > > > > > > repeated,
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > not trivial given the time and cost
> involved.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Xiang Xiao <xi...@gmail.com>
> > > > > > 于2026年10月16日周五
> > > > > > > > > > 15:08写道：
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > > > > > > > magicdcps@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Regarding your point about the NimBLE
> port
> > > > > using
> > > > > > > the
> > > > > > > > > > POSIX
> > > > > > > > > > > > API
> > > > > > > > > > > > > —
> > > > > > > > > > > > > > yes,
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > uses POSIX, but there are real issues
> with
> > > > the
> > > > > > > > current
> > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > go beyond just kernel/protected mode
> > > support.
> > > > > > > > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a
> real
> > > > > > critical
> > > > > > > > > > section
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Look at the NuttX port's
> implementation:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > uint32_t
> ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This is a mutex, not a critical
> section. It
> > > > > does
> > > > > > > not
> > > > > > > > > > > disable
> > > > > > > > > > > > > > > > interrupts
> > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > preemption — an ISR can still fire and
> > > > corrupt
> > > > > > data
> > > > > > > > > that
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > "critical
> > > > > > > > > > > > > > > > > > > section" was supposed to protect. On
> top of
> > > > > that,
> > > > > > > > > using a
> > > > > > > > > > > > mutex
> > > > > > > > > > > > > > opens
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > door to ABBA deadlocks when combined
> with
> > > any
> > > > > > other
> > > > > > > > > lock
> > > > > > > > > > > held
> > > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > critical region:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > - Thread A: enter_critical →
> > > > lock(s_mutex) →
> > > > > > try
> > > > > > > > > > > > lock(mutex
> > > > > > > > > > > > > > M) ←
> > > > > > > > > > > > > > > > > > blocked
> > > > > > > > > > > > > > > > > > > by B
> > > > > > > > > > > > > > > > > > > - Thread B: lock(M) →
> enter_critical →
> > > > > > > > > lock(s_mutex) ←
> > > > > > > > > > > > > > blocked by
> > > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Compare this with the FreeRTOS port,
> which
> > > > > > > correctly
> > > > > > > > > uses
> > > > > > > > > > > > > > > > > > > vPortEnterCritical() /
> vPortExitCritical()
> > > > > (i.e.,
> > > > > > > > > > actually
> > > > > > > > > > > > > > disabling
> > > > > > > > > > > > > > > > > > > scheduling/preemption). The current
> NuttX
> > > > port
> > > > > > > simply
> > > > > > > > > > does
> > > > > > > > > > > > not
> > > > > > > > > > > > > > meet
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > semantic contract that the NimBLE stack
> > > > expects
> > > > > > > from
> > > > > > > > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > > > > > > > 2. Time subsystem uses clock_gettime
> > > instead
> > > > of
> > > > > > > > kernel
> > > > > > > > > > tick
> > > > > > > > > > > > > APIs
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > > > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > > > > > > > ...),
> > > > > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > > involves a syscall and floating-point
> > > > > arithmetic
> > > > > > on
> > > > > > > > > every
> > > > > > > > > > > > call.
> > > > > > > > > > > > > > In a
> > > > > > > > > > > > > > > > > BLE
> > > > > > > > > > > > > > > > > > > stack where timestamps and timing are
> on
> > > the
> > > > > hot
> > > > > > > > path,
> > > > > > > > > > this
> > > > > > > > > > > > > adds
> > > > > > > > > > > > > > > > > > measurable
> > > > > > > > > > > > > > > > > > > overhead compared to accessing the
> kernel
> > > > tick
> > > > > > > > counter
> > > > > > > > > > > > > directly.
> > > > > > > > > > > > > > > > > > > 3. Others are already using the kernel
> > > > > approach —
> > > > > > > and
> > > > > > > > > for
> > > > > > > > > > > > good
> > > > > > > > > > > > > > reason
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth
> > > stack
> > > > > > > (zblue)
> > > > > > > > > for
> > > > > > > > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > > > > > > > uses kernel APIs directly, bypassing
> POSIX
> > > > for
> > > > > > the
> > > > > > > > > > > > > > > > performance-critical
> > > > > > > > > > > > > > > > > > > paths:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This isn't an academic exercise — it's
> a
> > > > > > production
> > > > > > > > > > choice.
> > > > > > > > > > > > > They
> > > > > > > > > > > > > > > > > > recognized
> > > > > > > > > > > > > > > > > > > that a BLE stack needs tight
> integration
> > > with
> > > > > the
> > > > > > > OS
> > > > > > > > > > timer
> > > > > > > > > > > > > > subsystem,
> > > > > > > > > > > > > > > > > > > direct access to critical section
> > > primitives,
> > > > > and
> > > > > > > > > > efficient
> > > > > > > > > > > > > event
> > > > > > > > > > > > > > > > > > delivery,
> > > > > > > > > > > > > > > > > > > none of which POSIX provides well in
> this
> > > > > > context.
> > > > > > > > > > > > > > > > > > > My question
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > If other organizations are already
> using a
> > > > more
> > > > > > > > > > performant,
> > > > > > > > > > > > > > > > > > architecturally
> > > > > > > > > > > > > > > > > > > correct kernel-level integration for
> their
> > > > BLE
> > > > > > > stacks
> > > > > > > > > on
> > > > > > > > > > > > NuttX,
> > > > > > > > > > > > > > why
> > > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > > we be told that we must use the slower,
> > > less
> > > > > > > correct
> > > > > > > > > > POSIX
> > > > > > > > > > > > > path?
> > > > > > > > > > > > > > > > > NuttX's
> > > > > > > > > > > > > > > > > > > POSIX compliance is valuable, but it
> > > > shouldn't
> > > > > > come
> > > > > > > > at
> > > > > > > > > > the
> > > > > > > > > > > > cost
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > shipping
> > > > > > > > > > > > > > > > > > > a BLE stack with a broken critical
> section
> > > > > > > primitive.
> > > > > > > > > > There
> > > > > > > > > > > > > > should be
> > > > > > > > > > > > > > > > > > room
> > > > > > > > > > > > > > > > > > > for both approaches, and the decision
> > > should
> > > > be
> > > > > > > > driven
> > > > > > > > > by
> > > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > > merit,
> > > > > > > > > > > > > > > > > > > not by treating POSIX as the only
> > > acceptable
> > > > > > > answer.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't object to moving the key
> bluetooth
> > > > stack
> > > > > to
> > > > > > > > > kernel
> > > > > > > > > > > > space
> > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > how
> > > > > > > > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > > > > > > > what I object to is that the current
> state of
> > > > > > > > > > > > > > > > > >
> https://github.com/apache/nuttx/pull/20686
> > > is
> > > > > far
> > > > > > to
> > > > > > > > > move
> > > > > > > > > > > > > entirely
> > > > > > > > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > > > > > > > If I low my quality bar, I have
> requested my
> > > > > > teammate
> > > > > > > > to
> > > > > > > > > > > > upstream
> > > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > > implementation:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > > > > since much work needs to be done before
> it
> > > can
> > > > > > > achieve
> > > > > > > > > the
> > > > > > > > > > > > > quality
> > > > > > > > > > > > > > > > > > upstream.
> > > > > > > > > > > > > > > > > > BTW, many zephyr class BT features are
> > > > developed
> > > > > by
> > > > > > > my
> > > > > > > > > team
> > > > > > > > > > > and
> > > > > > > > > > > > > > > > upstream
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > > > > > > > If considering the quality, our version
> is
> > > much
> > > > > > > better
> > > > > > > > > > since:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2
> > > > certification
> > > > > > at
> > > > > > > > > > 2026.06
> > > > > > > > > > > > > > > > > > 3. Product on wear device by end of
> this
> > > > year
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Tomek CEDRO <to...@cedro.info>.
Thank you Anchao and Alan :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Thu, Oct 22, 2026 at 1:46 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> Great, thank you very much Anchao!
>
> On Thu, Oct 22, 2026 at 10:36 AM chao an <ma...@gmail.com> wrote:
>
> > Hi Alan,
> >
> >
> >
> > Thanks for the suggestion and for offering to help with testing!
> >
> >
> >
> > I agree with your point. It is better to avoid introducing net/bt as an
> >
> > intermediate layout if we already know it will be moved later, since that
> >
> > would create unnecessary churn and could become a breaking change after
> >
> > merge.
> >
> >
> >
> > I have updated the patch accordingly:
> >
> >
> >
> > - Moved the Bluetooth host stack build integration out of net/
> >
> > - Kept the implementation under libs/zblue
> >
> > - Added libs/zblue as a standalone NuttX library, similar to other libs/*
> >
> > components
> >
> > - Moved the Kconfig entry under the top-level Wireless Support menu
> >
> > - Registered libzblue through the standard Make library target flow
> >
> > - Reworked the Make.defs paths to use TOPDIR-based paths instead of
> > relative
> > ../libs/zblue paths
> >
> >
> >
> > I also re-tested the integration with the sim:bt configuration, and the
> > native
> > Make build passes. I re-ran nxstyle and codespell as well, and both are
> > clean.
> >
> >
> > For the Kconfig selection, I agree that more explicit options will make it
> >
> > easier for users to enable only the parts they need. I will continue
> > refining
> > that so the stack is not exposed as one overly broad switch.
> >
> >
> >
> > Thanks again for the review and for working on the BT side too. Any
> > additional
> > testing from your side would be very welcome.
> >
> >
> >
> > BR,
> >
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 20:28写道：
> >
> > > Hi Anchao,
> > >
> > > Sounds good!
> > >
> > > Yes, I suggest going with more explicitly selection in the Kconfig so
> > users
> > > can select what they want more easily.
> > >
> > > Regarding "net/bt," there is not a more permanent solution than a
> > temporary
> > > one. This is a reason to avoid it.
> > >
> > > I understand that you tested the integration this way and agreed to
> > change
> > > it to libs/zblue later, but I strongly recommend making that change
> > before
> > > merging.
> > >
> > > Adding something that will probably change will result in a "breaking
> > > change" later, which we are trying to avoid on NuttX.
> > >
> > > So the best moment to change it is before it gets merged. If you need
> > help
> > > testing, I can assist here. I'm already working on BT (first fixing small
> > > issues).
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Thu, Oct 22, 2026 at 8:55 AM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > Yes, I agree that we need to find a middle ground and make sure the
> > > > integration does not block the existing Bluetooth solutions in NuttX.
> > > >
> > > > From the current implementation, I don't think this zblue-based stack
> > > > conflicts with NimBLE or with the existing in-tree BLE stack. They can
> > be
> > > > selected independently through Kconfig. For example:
> > > >
> > > > - CONFIG_BT Enables the new zblue-based host stack currently added
> > by
> > > > this PR.
> > > > - CONFIG_WIRELESS_BLUETOOTH
> > > > - CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE stack
> > > > under wireless/bluetooth.
> > > > - CONFIG_NIMBLE Enables the userspace NimBLE stack when that stack
> > is
> > > > used from apps.
> > > >
> > > > The lower-level Bluetooth controller / transport drivers are also
> > > separate,
> > > > for example:
> > > >
> > > > - CONFIG_BLUETOOTH_UART
> > > > - CONFIG_BLUETOOTH_RPMSG
> > > > - CONFIG_BLUETOOTH_NULL
> > > >
> > > > So I think it is possible to make the three options coexist on NuttX,
> > as
> > > > long as we keep the host-stack selection separated and avoid enabling
> > two
> > > > host stacks for the same controller path at the same time. If needed,
> > we
> > > > can also make this more explicit by adding a Kconfig choice or mutual
> > > > exclusion between the host stacks.
> > > >
> > > > Regarding the location, I understand your point about libs/zblue.
> > > However,
> > > > for the initial version, I still think keeping the full stack under
> > > net/bt
> > > > is the safer integration path.
> > > >
> > > > The reason is that splitting it into libs/zblue is not only a directory
> > > > rename. To do that correctly, we need to isolate each profile and data
> > > path
> > > > according to its own characteristics. Some profiles are not just pure
> > > > userspace library logic. For example, SCO and LE Audio / ISO have
> > > > lower-level data paths. On Linux, part of this kind of traffic is
> > handled
> > > > or forwarded by the kernel side. So if we move everything to libs/zblue
> > > too
> > > > early, we may create an artificial boundary that is not correct for
> > those
> > > > lower-level profiles.
> > > >
> > > > My suggestion is:
> > > >
> > > > 1. Keep the initial version integrated under net/bt, so the
> > > controller,
> > > > HCI, L2CAP, ISO/SCO and profile paths can work correctly first.
> > > > 2. Make the stack name clear as zblue if the community prefers that,
> > > so
> > > > it is not presented as replacing the existing NuttX BLE stack.
> > > > 3. Keep the Kconfig separation so users can choose between:
> > > > - zblue-based stack,
> > > > - existing NuttX BLE stack,
> > > > - NimBLE userspace stack.
> > > > 4. After the initial integration is stable, we can evaluate moving
> > or
> > > > splitting parts into libs/zblue profile by profile, where the
> > boundary
> > > > is
> > > > technically clear.
> > > >
> > > > So yes, I think it is possible to modify the PR to let both stacks plus
> > > > NimBLE work on NuttX without interfering with each other. I just think
> > > > doing a full libs/zblue separation as the first step may be risky,
> > > > especially for the lower-level profiles and audio-related paths.
> > > >
> > > > Does this direction sound acceptable to you?
> > > >
> > > > BR,
> > > >
> > > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 19:32写道：
> > > >
> > > > > Hi Anchao,
> > > > >
> > > > > Yes, I think having a complete BLE stack like zblue is a good idea.
> > > > >
> > > > > But we need to find a middle ground for correct integration.
> > > > >
> > > > > Let's do this: add zblue to libs/zglue and maintain a proper
> > separation
> > > > to
> > > > > allow room for the existing BLE stack on NuttX to evolve.
> > > > >
> > > > > Just assuming that not updating/synchroning zblue with Zephyr's zblue
> > > > will
> > > > > be enough for them to become different entities seems incorrect.
> > > > >
> > > > > The amount of code is very large, so even after decades they will
> > share
> > > > > enough of their "DNA" that a virus will be able to infect both.
> > > > >
> > > > > Do you think it is possible to modify your PR to let both stacks (+
> > > > NimBLE
> > > > > userspace stack) work on NuttX without one interfering on the other?
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thank you for the detailed analysis.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I understand your concern. The current code structure is indeed
> > still
> > > > > very
> > > > > >
> > > > > > close to Zephyr's Bluetooth stack, and the compatibility layer is
> > > > > currently
> > > > > >
> > > > > > quite thin. However, from the long-term technical direction, our
> > > > > intention
> > > > > > is
> > > > > > not to keep doing long-term synchronization with Zephyr. Instead,
> > we
> > > > plan
> > > > > > to
> > > > > > quickly feed back the related issues and improvements to the NuttX
> > > > > > community
> > > > > > during the integration and evolution process.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regarding the naming concern, I think it is reasonable to call it
> > > zblue
> > > > > >
> > > > > > temporarily, since the current implementation is still largely
> > based
> > > on
> > > > > >
> > > > > > Zephyr's Bluetooth stack. If the stack evolves later with a new
> > code
> > > > > > structure
> > > > > > and clearer NuttX-specific architecture, we can further evaluate
> > > > whether
> > > > > a
> > > > > >
> > > > > > different name would be more appropriate at that time.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Does that sound reasonable to you?
> > > > > >
> > > > > >
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > >
> > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> > > > > >
> > > > > > > Hi Anchao,
> > > > > > >
> > > > > > > I used Claude to help compare the code and here are the reasons
> > to
> > > > call
> > > > > > it
> > > > > > > zblue instead of libs/bt:
> > > > > > >
> > > > > > > Almost all of this PR is Zephyr's Bluetooth stack
> > > > > > > ("zblue"), reformatted to NuttX style. The part that doesn't come
> > > > from
> > > > > > > Zephyr is
> > > > > > > a thin compatibility layer that makes the Zephyr kernel calls
> > work
> > > on
> > > > > > > NuttX.
> > > > > > >
> > > > > > > I pulled all 539 new files (400,450 lines) and compared them
> > > against
> > > > > > > several
> > > > > > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it
> > > > matches
> > > > > > > better
> > > > > > > than Zephyr's current main branch. So the PR looks like a
> > snapshot
> > > of
> > > > > > zblue
> > > > > > > from the last few weeks.
> > > > > > >
> > > > > > > Results
> > > > > > >
> > > > > > > Function by function (7,716 functions):
> > > > > > >
> > > > > > > Class: Identical
> > > > > > > Functions: 5,411 (70%)
> > > > > > > Lines: 140,189
> > > > > > > Meaning: Exactly the same code as Zephyr. Only indentation and
> > > > braces
> > > > > > > differ.
> > > > > > > ────────────────────────────────────────
> > > > > > > Class: Renames only
> > > > > > > Functions: 1,515 (20%)
> > > > > > > Lines: 60,863
> > > > > > > Meaning: The only changes are API renames that recur across the
> > > > whole
> > > > > > PR:
> > > > > > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> > > > > > sys_slist_*→list_*,
> > > > > > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post,
> > > atomic_get→atomic_read
> > > > > > > ────────────────────────────────────────
> > > > > > > Class: Modified
> > > > > > > Functions: 584 (8%)
> > > > > > > Lines: 33,693
> > > > > > > Meaning: Clearly the Zephyr function, plus some edits specific
> > to
> > > > > that
> > > > > > > function
> > > > > > > ────────────────────────────────────────
> > > > > > > Class: Not from Zephyr
> > > > > > > Functions: 206 (3%)
> > > > > > > Lines: 2,734
> > > > > > > Meaning: NuttX glue code
> > > > > > >
> > > > > > > Whole files, including headers:
> > > > > > > - On average, 96.9% of each file's code also appears in its
> > > Zephyr
> > > > > > > counterpart.
> > > > > > > - 434 of the 539 files are ≥90% the same as Zephyr; together
> > they
> > > > > hold
> > > > > > > 375k of
> > > > > > > the 400k lines.
> > > > > > > - 75% of the comment text, including the Doxygen docs, is
> > > > > word-for-word
> > > > > > > Zephyr.
> > > > > > >
> > > > > > > What's actually new:
> > > > > > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c,
> > > > > mem_slab.c,
> > > > > > > fs.c,
> > > > > > > sections/defines.c, hci_driver.c), which provides k_work,
> > > k_queue
> > > > > and
> > > > > > > similar
> > > > > > > Zephyr calls on top of NuttX.
> > > > > > > - Part of mm/net_buf.
> > > > > > > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > > > > > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt
> > > defconfig.
> > > > > > >
> > > > > > >
> > > > > > > So, only 3% of the code is new (this includes the code in sim:bt
> > > that
> > > > > > must
> > > > > > > be new).
> > > > > > >
> > > > > > > So, reusing the zblue from Zephyr and calling it something else
> > > isn't
> > > > > > > right; it's like the zbus that Jorge brought from Zephyr, where
> > > > calling
> > > > > > it
> > > > > > > NXBus doesn't seem appropriate.
> > > > > > >
> > > > > > > Besides that, as I said before using ZBlue as our official BT
> > Stack
> > > > > will
> > > > > > > significantly increase the shared code between NuttX and Zephyr,
> > > > which
> > > > > > > could be dangerous.
> > > > > > >
> > > > > > > As I said, I not against adding ZBlue to NuttX, but at least make
> > > it
> > > > > > clear
> > > > > > > that it is ZBlue and should be an alternative stack (like NimBLE)
> > > not
> > > > > the
> > > > > > > official NuttX BLE Stack.
> > > > > > >
> > > > > > > BR,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > > On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > > Hi Alan,
> > > > > > > >
> > > > > > > > Thanks for the comments and suggestions.
> > > > > > > >
> > > > > > > > For the first stage, I would prefer to keep the Bluetooth host
> > > > stack
> > > > > > > > supported only in FLAT mode. Supporting Protected and Kernel
> > > modes
> > > > > > > requires
> > > > > > > > a much deeper rework of the stack and its interfaces,
> > especially
> > > > > around
> > > > > > > the
> > > > > > > > boundary between kernel space and user space. I do not think it
> > > is
> > > > a
> > > > > > good
> > > > > > > > idea to introduce such large architectural changes in this
> > first
> > > > > step.
> > > > > > > >
> > > > > > > > Our current plan is to complete Protected/Kernel mode support
> > in
> > > a
> > > > > > second
> > > > > > > > stage, after the basic stack integration is reviewed and
> > > > stabilized.
> > > > > > This
> > > > > > > > should make the initial review and integration much more
> > > > manageable.
> > > > > > > >
> > > > > > > > Regarding the library name, I still prefer to use libs/libbt.
> > > > > Although
> > > > > > > the
> > > > > > > > current code is based on Zephyr's zblue, the goal is to
> > maintain
> > > it
> > > > > as
> > > > > > an
> > > > > > > > independent NuttX Bluetooth host stack going forward, rather
> > than
> > > > > > keeping
> > > > > > > > it as a direct Zephyr fork forever. In that sense, I think
> > libbt
> > > > is a
> > > > > > > > better long-term name.
> > > > > > > >
> > > > > > > > Also, the current NuttX Bluetooth profiles are not implemented
> > in
> > > > the
> > > > > > > > kernel, and we do not plan to move the native NuttX Bluetooth
> > > stack
> > > > > > > > profiles into the kernel either. Once Protected/Kernel mode
> > > support
> > > > > is
> > > > > > > > added for this stack in the future, this implementation is
> > > expected
> > > > > to
> > > > > > > > replace the previous approach. For this reason, I think keeping
> > > the
> > > > > > stack
> > > > > > > > under libbt is still more appropriate.
> > > > > > > >
> > > > > > > > About splitting the PR: this PR is already the result of
> > > squashing
> > > > > more
> > > > > > > > than one hundred commits. Most of those commits are
> > > > > compatibility-layer
> > > > > > > > adjustments, coding style cleanup, and mechanical changes
> > needed
> > > to
> > > > > > make
> > > > > > > > the stack build in NuttX. Asking reviewers to review each of
> > > those
> > > > > > > commits
> > > > > > > > separately would probably cost everyone more time.
> > > > > > > >
> > > > > > > > Splitting the full Bluetooth stack by profile is also not very
> > > > > > practical
> > > > > > > at
> > > > > > > > the moment, because there are no dedicated maintainers for each
> > > > > > > individual
> > > > > > > > Bluetooth profile area in NuttX yet. Therefore, I think the
> > > current
> > > > > > form
> > > > > > > is
> > > > > > > > probably the most reasonable way to review and integrate the
> > > stack
> > > > > as a
> > > > > > > > whole.
> > > > > > > >
> > > > > > > > One more update: I have removed all shell-related code from
> > > > > > > > https://github.com/apache/nuttx/pull/20686. The plan is to
> > move
> > > > > those
> > > > > > > > shell
> > > > > > > > commands to apps later. With this change, the current Bluetooth
> > > > stack
> > > > > > no
> > > > > > > > longer contains any user-space shell code, so I think this is
> > > now a
> > > > > > > better
> > > > > > > > point for review.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > >
> > > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > > > > > > >
> > > > > > > > > Hi An Chao,
> > > > > > > > >
> > > > > > > > > Isn't it possible to have a similar implementation that works
> > > for
> > > > > > FLAT,
> > > > > > > > > Protected and Kernel modes?
> > > > > > > > >
> > > > > > > > > This way the maintenance will be easier. Only small
> > > > kernel-specific
> > > > > > > parts
> > > > > > > > > will remain there (as Raiden and Xiang proposed).
> > > > > > > > >
> > > > > > > > > Suggestion: instead of naming it libs/libbt/, it would be
> > > better
> > > > to
> > > > > > use
> > > > > > > > > libs/zblue to make it clear that it is a zblue port from
> > > Zephyr.
> > > > > > > > >
> > > > > > > > > Let's use libs/libbt only for NuttX-specific (native) code.
> > > > > > > > >
> > > > > > > > > And as I said, it is better to easily isolate the code that
> > > came
> > > > > from
> > > > > > > > > Zephyr's zblue.
> > > > > > > > >
> > > > > > > > > This way the user could select the Bluetooth stack they want
> > > > > without
> > > > > > > > having
> > > > > > > > > code from the other stack attached to it.
> > > > > > > > >
> > > > > > > > > Also I suggest you to break your PR into smaller PRs; a
> > single
> > > PR
> > > > > > > > changing
> > > > > > > > > more than 660K LoC is very massive.
> > > > > > > > >
> > > > > > > > > BR,
> > > > > > > > >
> > > > > > > > > Alan
> > > > > > > > >
> > > > > > > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <magicdcps@gmail.com
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Alan,
> > > > > > > > > >
> > > > > > > > > > Thank you for the thoughtful perspective and for engaging
> > in
> > > > the
> > > > > > > > > > discussion.
> > > > > > > > > >
> > > > > > > > > > On security: we will maintain the Bluetooth stack ourselves
> > > and
> > > > > > take
> > > > > > > > > > responsibility for tracking and fixing vulnerabilities. I'm
> > > > also
> > > > > > > > > confident
> > > > > > > > > > that Xiaomi will contribute back on security issues given
> > > their
> > > > > > > ongoing
> > > > > > > > > > investment in this codebase. This isn't a blind import —
> > it's
> > > > > code
> > > > > > > that
> > > > > > > > > has
> > > > > > > > > > active, committed maintainers behind it.
> > > > > > > > > >
> > > > > > > > > > Regarding the history with Greg: you're right that we
> > > discussed
> > > > > > this
> > > > > > > > > years
> > > > > > > > > > ago. But there's an important distinction — that earlier
> > > > proposal
> > > > > > > > placed
> > > > > > > > > > the stack entirely in userspace. It did nothing to
> > strengthen
> > > > > > NuttX's
> > > > > > > > > > kernel-level Bluetooth support. That's precisely why I'm
> > back
> > > > > now,
> > > > > > > > > > providing a kernel implementation this time around, which
> > is
> > > > > what I
> > > > > > > > > > committed to back then. Feel free to search the mailing
> > list
> > > > > > > archives —
> > > > > > > > > the
> > > > > > > > > > NuttX native Bluetooth stack will evolve from this baseline
> > > > going
> > > > > > > > > forward.
> > > > > > > > > >
> > > > > > > > > > This implementation does not affect existing Bluetooth
> > stacks
> > > > in
> > > > > > any
> > > > > > > > way.
> > > > > > > > > > Users can still choose NimBLE, the current NuttX BLE stack,
> > > or
> > > > > any
> > > > > > > > other
> > > > > > > > > > solution. This is an additional option, not a replacement.
> > > The
> > > > > goal
> > > > > > > is
> > > > > > > > to
> > > > > > > > > > give NuttX users more choices, not fewer.
> > > > > > > > > >
> > > > > > > > > > One more update: I just spoke with Xiaoxiang and we've
> > > reached
> > > > > some
> > > > > > > > > common
> > > > > > > > > > ground. He's no longer opposed to the current stack
> > > > > implementation
> > > > > > > and
> > > > > > > > > > agrees that the focus should be on proper structuring.
> > Here's
> > > > the
> > > > > > > plan
> > > > > > > > > > going forward:
> > > > > > > > > >
> > > > > > > > > > 1. Unused shell code will be moved out of the stack and
> > > into
> > > > > > > apps/,
> > > > > > > > > > running entirely in userspace.
> > > > > > > > > > 2. Bluetooth profiles will be migrated to libs/libbt/,
> > > where
> > > > > > we'll
> > > > > > > > > > provide two OS API backends: a POSIX API implementation
> > > (for
> > > > > > > > > > kernel/protected builds) and a NuttX kernel API
> > > > implementation
> > > > > > > (for
> > > > > > > > > flat
> > > > > > > > > > mode).
> > > > > > > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > > > > > > >
> > > > > > > > > > This should address the architectural concerns while
> > > preserving
> > > > > the
> > > > > > > > > > performance path for flat-mode deployments.
> > > > > > > > > >
> > > > > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > > > > > > > >
> > > > > > > > > > > Hi An Chao,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for trying to improve the NuttX Bluetooth
> > > support.
> > > > > And
> > > > > > > > thank
> > > > > > > > > > you
> > > > > > > > > > > to bring this discussion here to let more people give
> > their
> > > > > > > opinion.
> > > > > > > > > > >
> > > > > > > > > > > I think most of the concerns raised by Xiang and Raiden
> > > > > (Mateusz)
> > > > > > > are
> > > > > > > > > > > important and need to be addressed.
> > > > > > > > > > >
> > > > > > > > > > > As I said at GitHub PR I think a main concern here is
> > using
> > > > the
> > > > > > > same
> > > > > > > > > > > Bluetooth stack used on Zephyr, not because it is a bad
> > > stack
> > > > > (of
> > > > > > > > > course
> > > > > > > > > > it
> > > > > > > > > > > is not, it was developed by experts on Bluetooth area),
> > but
> > > > > > because
> > > > > > > > we
> > > > > > > > > > are
> > > > > > > > > > > adding the same surface area of attack from Zephyr on
> > > NuttX.
> > > > > > > > > > >
> > > > > > > > > > > That means any security vulnerability affecting Zephyr
> > BLE
> > > > > stack
> > > > > > > will
> > > > > > > > > > > affect NuttX. It remove the protection that a companies
> > > could
> > > > > > > obtain
> > > > > > > > > when
> > > > > > > > > > > using different RTOSs.
> > > > > > > > > > >
> > > > > > > > > > > Also, if my memory still serving me, I think Xiaomi team
> > > (you
> > > > > was
> > > > > > > > there
> > > > > > > > > > at
> > > > > > > > > > > that time) already tried to submit their initial port of
> > > > Zephyr
> > > > > > BLE
> > > > > > > > > stack
> > > > > > > > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > > > > > > > >
> > > > > > > > > > > His suggestion was to improve our BLE stack, that in fact
> > > has
> > > > > the
> > > > > > > > same
> > > > > > > > > > > origin of the Zephyr BLE stack (both came from a BLE
> > stack
> > > > from
> > > > > > > Intel
> > > > > > > > > > > released as BSD license at that time).
> > > > > > > > > > >
> > > > > > > > > > > I'm not against including the Zephyr BLE stack, but it
> > > should
> > > > > be
> > > > > > > > > > > selectable. Ideally the user should select if he/she
> > wants
> > > to
> > > > > use
> > > > > > > > > NimBLE,
> > > > > > > > > > > Zephyr or NuttX native BLE stack.
> > > > > > > > > > >
> > > > > > > > > > > BR,
> > > > > > > > > > >
> > > > > > > > > > > Alan
> > > > > > > > > > >
> > > > > > > > > > > On Friday, October 16, 2026, chao an <
> > magicdcps@gmail.com>
> > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi, Tomek,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the thoughtful input and the FreeBSD
> > > references
> > > > —
> > > > > > > those
> > > > > > > > > are
> > > > > > > > > > > very
> > > > > > > > > > > > relevant to where we're heading.
> > > > > > > > > > > >
> > > > > > > > > > > > Just to set the context: NuttX's current Bluetooth
> > stack
> > > > only
> > > > > > > > > supports
> > > > > > > > > > > BLE.
> > > > > > > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are
> > all
> > > > > > > missing.
> > > > > > > > > This
> > > > > > > > > > > is
> > > > > > > > > > > > exactly why we want to bring a more complete Bluetooth
> > > > stack
> > > > > to
> > > > > > > > > NuttX —
> > > > > > > > > > > to
> > > > > > > > > > > > catch up with what mainstream RTOS communities already
> > > > offer.
> > > > > > > > > > > >
> > > > > > > > > > > > I actually agree with the FreeBSD/Apple architecture
> > you
> > > > > > > > referenced.
> > > > > > > > > > Our
> > > > > > > > > > > > end-state plan is similar: the L2CAP and HCI layers
> > will
> > > > live
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > > kernel, and a bluetoothd-style daemon will be
> > implemented
> > > > in
> > > > > > > libc,
> > > > > > > > > > > managing
> > > > > > > > > > > > profiles and higher-level protocols. This gives us a
> > > clean
> > > > > > > > > separation —
> > > > > > > > > > > > transport in the kernel, policy and profiles in
> > > userspace —
> > > > > > much
> > > > > > > > like
> > > > > > > > > > how
> > > > > > > > > > > > FreeBSD's ng_hci / hccontrol split works. The current
> > PR
> > > is
> > > > > > > Phase 1
> > > > > > > > > of
> > > > > > > > > > > > getting there incrementally.
> > > > > > > > > > > >
> > > > > > > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > > > > > > > >
> > > > > > > > > > > > > Thank you An Chao for this proposition, work, and
> > > > > discussion
> > > > > > > :-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > For sure it would be nice to have a BT stack with
> > more
> > > > > > > features!
> > > > > > > > > The
> > > > > > > > > > > > > BT has known issue of having different
> > implementations
> > > of
> > > > > the
> > > > > > > > stack
> > > > > > > > > > on
> > > > > > > > > > > > > different RTOS / OS / platforms, which is a known
> > > issue,
> > > > > and
> > > > > > > > kinda
> > > > > > > > > > > > > mess because there is no common standard / approach /
> > > > > > > > > implementation,
> > > > > > > > > > > > > unfortunately around something that is supposed to be
> > > > based
> > > > > > on
> > > > > > > a
> > > > > > > > > > > > > common standard.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Having common BT stack with other popular RTOS may
> > make
> > > > > > > > portability
> > > > > > > > > > > > > easier and developers move to NuttX in some cases.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I understand that we are talking about this solution?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > > > > > > connectivity/bluetooth/index.html
> > > > > > > > > > > > >
> > > > > > > > > > > > > In a perfect situation we would want to have modular
> > > > > > > > implementation
> > > > > > > > > > in
> > > > > > > > > > > > > nuttx-apps just like nimble. This is pointed out by
> > > > Xiang,
> > > > > > > > Raiden,
> > > > > > > > > > and
> > > > > > > > > > > > > Alin already. But I understand some things may be
> > hard
> > > to
> > > > > > > > implement
> > > > > > > > > > > > > that way. I will follow the consensus here when
> > ready,
> > > I
> > > > > have
> > > > > > > no
> > > > > > > > > > > > > strong opinion here, except any BT stack I touched
> > > before
> > > > > > was a
> > > > > > > > > mess
> > > > > > > > > > > > > and I hope we can work out at least something decent
> > > :-P
> > > > > > > > > > > > >
> > > > > > > > > > > > > A bit offtopic but for kernel build we can take a
> > look
> > > at
> > > > > > quite
> > > > > > > > old
> > > > > > > > > > > > > Bluetooth implementation on FreeBSD, where radio is
> > > > > provided
> > > > > > by
> > > > > > > > > > ng_ubt
> > > > > > > > > > > > > (lower half in out case), then upper half uses
> > standard
> > > > > HCI.
> > > > > > > > Maybe
> > > > > > > > > > > > > something like this is possible in NuttX?
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1.
> > https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > > > > > > 3.
> > https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > > > > > > 4.
> > > > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > > > > > > 5.
> > > > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here is a quick overview article on the Bluetooth
> > > > > > > implementation
> > > > > > > > in
> > > > > > > > > > > > > FreeBSD and Apple:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > > > > > > >
> > > > > > > > > > > > > Again it will be very nice to have fully featured BT
> > > > stack
> > > > > in
> > > > > > > > NuttX
> > > > > > > > > > > > > and I hope we can sort out the best possible porting
> > > > > > > > implementation
> > > > > > > > > > > > > :-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > > > > > > jerpelea@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > thanks Xiao and Raiden for your technical opinions
> > > > which
> > > > > I
> > > > > > > also
> > > > > > > > > > share
> > > > > > > > > > > > so
> > > > > > > > > > > > > I
> > > > > > > > > > > > > > will not iterate them again.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > > > > > > it should be splitted between nuttx and apps-repos
> > > and
> > > > > use
> > > > > > > > POSIX
> > > > > > > > > > > > > > implementation as much as possible. We are focused
> > on
> > > > > > > standards
> > > > > > > > > and
> > > > > > > > > > > > > > compatibility.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Another concern is the license which does not match
> > > our
> > > > > ASF
> > > > > > > one
> > > > > > > > > and
> > > > > > > > > > > > does
> > > > > > > > > > > > > > not include any LICENSE file additions to clarify
> > the
> > > > > > > compiance
> > > > > > > > > > > aspect
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Best regards
> > > > > > > > > > > > > > Alin J
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > > > > > > xiaoxiang781216@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > > > > > > magicdcps@gmail.com
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So the real reason you've been objecting to my
> > > > > proposal
> > > > > > > is
> > > > > > > > > that
> > > > > > > > > > > > your
> > > > > > > > > > > > > team
> > > > > > > > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If you can give me a clear timeline for when
> > your
> > > > > > > > > > implementation
> > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > submitted upstream, I'm happy to withdraw my PR
> > > and
> > > > > let
> > > > > > > > your
> > > > > > > > > > code
> > > > > > > > > > > > > serve
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > the baseline. I'm not here to fight over
> > > ownership
> > > > of
> > > > > > the
> > > > > > > > > > > Bluetooth
> > > > > > > > > > > > > > > stack.
> > > > > > > > > > > > > > > > My only motivation is that NuttX's lack of a
> > > > capable
> > > > > > > > > Bluetooth
> > > > > > > > > > > > stack
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > driving every developer toward Zephyr — and as
> > a
> > > > PMC
> > > > > > > > member,
> > > > > > > > > I
> > > > > > > > > > > > think
> > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > should be asking yourselves why this gap has
> > > > remained
> > > > > > > > > unfilled
> > > > > > > > > > > for
> > > > > > > > > > > > so
> > > > > > > > > > > > > > > long.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I object to landing the whole bluetooth stack
> > into
> > > > > kernel
> > > > > > > > space
> > > > > > > > > > > > > directly
> > > > > > > > > > > > > > > either yours and ours .
> > > > > > > > > > > > > > > This is the same feeling from raiden00pl too,
> > let's
> > > > see
> > > > > > > other
> > > > > > > > > > > > people's
> > > > > > > > > > > > > > > opinions here.
> > > > > > > > > > > > > > > But it's fine for me to host the whole code in
> > > > > > > nuttx-apps.git
> > > > > > > > > and
> > > > > > > > > > > > > refactor
> > > > > > > > > > > > > > > components to kernel
> > > > > > > > > > > > > > > space step by step.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As for the current PR, I'll remove the shell
> > > > > components
> > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > > stack
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > move them into apps/ where they belong. The
> > base
> > > > > > profiles
> > > > > > > > > > (A2DP,
> > > > > > > > > > > > BLE)
> > > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > > stay in libc —
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The architecture is wrong to host any bluetooth
> > > > > profile
> > > > > > in
> > > > > > > > > libc.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > in flat build mode this gives a significant
> > > > performance
> > > > > > > > > > > > > > > > boost to the overall stack, which is the
> > primary
> > > > > > > deployment
> > > > > > > > > > model
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > > NuttX devices.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Performance should remain the same whether the
> > base
> > > > > > profile
> > > > > > > > is
> > > > > > > > > > > hosted
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > libc or apps,
> > > > > > > > > > > > > > > could you point out any technical reason which
> > > > impacts
> > > > > > the
> > > > > > > > > > > > performance
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the flat mode?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > A few additional data points regarding our
> > > > timeline:
> > > > > > our
> > > > > > > > > > product
> > > > > > > > > > > is
> > > > > > > > > > > > > > > > scheduled for release in December, and
> > Bluetooth
> > > > SIG
> > > > > > > > > > > certification
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > already in progress — we expect to receive it
> > > > around
> > > > > > > > > November.
> > > > > > > > > > If
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > baseline were to switch to your team's stack
> > with
> > > > its
> > > > > > > > > different
> > > > > > > > > > > > > > > > architecture, that certification cycle would
> > need
> > > > to
> > > > > be
> > > > > > > > > > repeated,
> > > > > > > > > > > > > which
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Xiang Xiao <xi...@gmail.com>
> > > > > 于2026年10月16日周五
> > > > > > > > > 15:08写道：
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > > > > > > magicdcps@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Regarding your point about the NimBLE port
> > > > using
> > > > > > the
> > > > > > > > > POSIX
> > > > > > > > > > > API
> > > > > > > > > > > > —
> > > > > > > > > > > > > yes,
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > uses POSIX, but there are real issues with
> > > the
> > > > > > > current
> > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > go beyond just kernel/protected mode
> > support.
> > > > > > > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real
> > > > > critical
> > > > > > > > > section
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This is a mutex, not a critical section. It
> > > > does
> > > > > > not
> > > > > > > > > > disable
> > > > > > > > > > > > > > > interrupts
> > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > preemption — an ISR can still fire and
> > > corrupt
> > > > > data
> > > > > > > > that
> > > > > > > > > > the
> > > > > > > > > > > > > > > "critical
> > > > > > > > > > > > > > > > > > section" was supposed to protect. On top of
> > > > that,
> > > > > > > > using a
> > > > > > > > > > > mutex
> > > > > > > > > > > > > opens
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > door to ABBA deadlocks when combined with
> > any
> > > > > other
> > > > > > > > lock
> > > > > > > > > > held
> > > > > > > > > > > > > inside
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > critical region:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - Thread A: enter_critical →
> > > lock(s_mutex) →
> > > > > try
> > > > > > > > > > > lock(mutex
> > > > > > > > > > > > > M) ←
> > > > > > > > > > > > > > > > > blocked
> > > > > > > > > > > > > > > > > > by B
> > > > > > > > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > > > > > > > lock(s_mutex) ←
> > > > > > > > > > > > > blocked by
> > > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Compare this with the FreeRTOS port, which
> > > > > > correctly
> > > > > > > > uses
> > > > > > > > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical()
> > > > (i.e.,
> > > > > > > > > actually
> > > > > > > > > > > > > disabling
> > > > > > > > > > > > > > > > > > scheduling/preemption). The current NuttX
> > > port
> > > > > > simply
> > > > > > > > > does
> > > > > > > > > > > not
> > > > > > > > > > > > > meet
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > semantic contract that the NimBLE stack
> > > expects
> > > > > > from
> > > > > > > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > > > > > > 2. Time subsystem uses clock_gettime
> > instead
> > > of
> > > > > > > kernel
> > > > > > > > > tick
> > > > > > > > > > > > APIs
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > > > > > > ...),
> > > > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > involves a syscall and floating-point
> > > > arithmetic
> > > > > on
> > > > > > > > every
> > > > > > > > > > > call.
> > > > > > > > > > > > > In a
> > > > > > > > > > > > > > > > BLE
> > > > > > > > > > > > > > > > > > stack where timestamps and timing are on
> > the
> > > > hot
> > > > > > > path,
> > > > > > > > > this
> > > > > > > > > > > > adds
> > > > > > > > > > > > > > > > > measurable
> > > > > > > > > > > > > > > > > > overhead compared to accessing the kernel
> > > tick
> > > > > > > counter
> > > > > > > > > > > > directly.
> > > > > > > > > > > > > > > > > > 3. Others are already using the kernel
> > > > approach —
> > > > > > and
> > > > > > > > for
> > > > > > > > > > > good
> > > > > > > > > > > > > reason
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth
> > stack
> > > > > > (zblue)
> > > > > > > > for
> > > > > > > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX
> > > for
> > > > > the
> > > > > > > > > > > > > > > performance-critical
> > > > > > > > > > > > > > > > > > paths:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This isn't an academic exercise — it's a
> > > > > production
> > > > > > > > > choice.
> > > > > > > > > > > > They
> > > > > > > > > > > > > > > > > recognized
> > > > > > > > > > > > > > > > > > that a BLE stack needs tight integration
> > with
> > > > the
> > > > > > OS
> > > > > > > > > timer
> > > > > > > > > > > > > subsystem,
> > > > > > > > > > > > > > > > > > direct access to critical section
> > primitives,
> > > > and
> > > > > > > > > efficient
> > > > > > > > > > > > event
> > > > > > > > > > > > > > > > > delivery,
> > > > > > > > > > > > > > > > > > none of which POSIX provides well in this
> > > > > context.
> > > > > > > > > > > > > > > > > > My question
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If other organizations are already using a
> > > more
> > > > > > > > > performant,
> > > > > > > > > > > > > > > > > architecturally
> > > > > > > > > > > > > > > > > > correct kernel-level integration for their
> > > BLE
> > > > > > stacks
> > > > > > > > on
> > > > > > > > > > > NuttX,
> > > > > > > > > > > > > why
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > we be told that we must use the slower,
> > less
> > > > > > correct
> > > > > > > > > POSIX
> > > > > > > > > > > > path?
> > > > > > > > > > > > > > > > NuttX's
> > > > > > > > > > > > > > > > > > POSIX compliance is valuable, but it
> > > shouldn't
> > > > > come
> > > > > > > at
> > > > > > > > > the
> > > > > > > > > > > cost
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > shipping
> > > > > > > > > > > > > > > > > > a BLE stack with a broken critical section
> > > > > > primitive.
> > > > > > > > > There
> > > > > > > > > > > > > should be
> > > > > > > > > > > > > > > > > room
> > > > > > > > > > > > > > > > > > for both approaches, and the decision
> > should
> > > be
> > > > > > > driven
> > > > > > > > by
> > > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > > merit,
> > > > > > > > > > > > > > > > > > not by treating POSIX as the only
> > acceptable
> > > > > > answer.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't object to moving the key bluetooth
> > > stack
> > > > to
> > > > > > > > kernel
> > > > > > > > > > > space
> > > > > > > > > > > > > like
> > > > > > > > > > > > > > > how
> > > > > > > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > > > > > > > https://github.com/apache/nuttx/pull/20686
> > is
> > > > far
> > > > > to
> > > > > > > > move
> > > > > > > > > > > > entirely
> > > > > > > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > > > > > > If I low my quality bar, I have requested my
> > > > > teammate
> > > > > > > to
> > > > > > > > > > > upstream
> > > > > > > > > > > > > our
> > > > > > > > > > > > > > > > > implementation:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > > > since much work needs to be done before it
> > can
> > > > > > achieve
> > > > > > > > the
> > > > > > > > > > > > quality
> > > > > > > > > > > > > > > > > upstream.
> > > > > > > > > > > > > > > > > BTW, many zephyr class BT features are
> > > developed
> > > > by
> > > > > > my
> > > > > > > > team
> > > > > > > > > > and
> > > > > > > > > > > > > > > upstream
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > > > > > > If considering the quality, our version is
> > much
> > > > > > better
> > > > > > > > > since:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2
> > > certification
> > > > > at
> > > > > > > > > 2026.06
> > > > > > > > > > > > > > > > > 3. Product on wear device by end of this
> > > year
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by "Alan C. Assis" <ac...@gmail.com>.
Great, thank you very much Anchao!
On Thu, Oct 22, 2026 at 10:36 AM chao an <ma...@gmail.com> wrote:
> Hi Alan,
>
>
>
> Thanks for the suggestion and for offering to help with testing!
>
>
>
> I agree with your point. It is better to avoid introducing net/bt as an
>
> intermediate layout if we already know it will be moved later, since that
>
> would create unnecessary churn and could become a breaking change after
>
> merge.
>
>
>
> I have updated the patch accordingly:
>
>
>
> - Moved the Bluetooth host stack build integration out of net/
>
> - Kept the implementation under libs/zblue
>
> - Added libs/zblue as a standalone NuttX library, similar to other libs/*
>
> components
>
> - Moved the Kconfig entry under the top-level Wireless Support menu
>
> - Registered libzblue through the standard Make library target flow
>
> - Reworked the Make.defs paths to use TOPDIR-based paths instead of
> relative
> ../libs/zblue paths
>
>
>
> I also re-tested the integration with the sim:bt configuration, and the
> native
> Make build passes. I re-ran nxstyle and codespell as well, and both are
> clean.
>
>
> For the Kconfig selection, I agree that more explicit options will make it
>
> easier for users to enable only the parts they need. I will continue
> refining
> that so the stack is not exposed as one overly broad switch.
>
>
>
> Thanks again for the review and for working on the BT side too. Any
> additional
> testing from your side would be very welcome.
>
>
>
> BR,
>
>
> Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 20:28写道：
>
> > Hi Anchao,
> >
> > Sounds good!
> >
> > Yes, I suggest going with more explicitly selection in the Kconfig so
> users
> > can select what they want more easily.
> >
> > Regarding "net/bt," there is not a more permanent solution than a
> temporary
> > one. This is a reason to avoid it.
> >
> > I understand that you tested the integration this way and agreed to
> change
> > it to libs/zblue later, but I strongly recommend making that change
> before
> > merging.
> >
> > Adding something that will probably change will result in a "breaking
> > change" later, which we are trying to avoid on NuttX.
> >
> > So the best moment to change it is before it gets merged. If you need
> help
> > testing, I can assist here. I'm already working on BT (first fixing small
> > issues).
> >
> > BR,
> >
> > Alan
> >
> > On Thu, Oct 22, 2026 at 8:55 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi Alan,
> > >
> > > Yes, I agree that we need to find a middle ground and make sure the
> > > integration does not block the existing Bluetooth solutions in NuttX.
> > >
> > > From the current implementation, I don't think this zblue-based stack
> > > conflicts with NimBLE or with the existing in-tree BLE stack. They can
> be
> > > selected independently through Kconfig. For example:
> > >
> > > - CONFIG_BT Enables the new zblue-based host stack currently added
> by
> > > this PR.
> > > - CONFIG_WIRELESS_BLUETOOTH
> > > - CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE stack
> > > under wireless/bluetooth.
> > > - CONFIG_NIMBLE Enables the userspace NimBLE stack when that stack
> is
> > > used from apps.
> > >
> > > The lower-level Bluetooth controller / transport drivers are also
> > separate,
> > > for example:
> > >
> > > - CONFIG_BLUETOOTH_UART
> > > - CONFIG_BLUETOOTH_RPMSG
> > > - CONFIG_BLUETOOTH_NULL
> > >
> > > So I think it is possible to make the three options coexist on NuttX,
> as
> > > long as we keep the host-stack selection separated and avoid enabling
> two
> > > host stacks for the same controller path at the same time. If needed,
> we
> > > can also make this more explicit by adding a Kconfig choice or mutual
> > > exclusion between the host stacks.
> > >
> > > Regarding the location, I understand your point about libs/zblue.
> > However,
> > > for the initial version, I still think keeping the full stack under
> > net/bt
> > > is the safer integration path.
> > >
> > > The reason is that splitting it into libs/zblue is not only a directory
> > > rename. To do that correctly, we need to isolate each profile and data
> > path
> > > according to its own characteristics. Some profiles are not just pure
> > > userspace library logic. For example, SCO and LE Audio / ISO have
> > > lower-level data paths. On Linux, part of this kind of traffic is
> handled
> > > or forwarded by the kernel side. So if we move everything to libs/zblue
> > too
> > > early, we may create an artificial boundary that is not correct for
> those
> > > lower-level profiles.
> > >
> > > My suggestion is:
> > >
> > > 1. Keep the initial version integrated under net/bt, so the
> > controller,
> > > HCI, L2CAP, ISO/SCO and profile paths can work correctly first.
> > > 2. Make the stack name clear as zblue if the community prefers that,
> > so
> > > it is not presented as replacing the existing NuttX BLE stack.
> > > 3. Keep the Kconfig separation so users can choose between:
> > > - zblue-based stack,
> > > - existing NuttX BLE stack,
> > > - NimBLE userspace stack.
> > > 4. After the initial integration is stable, we can evaluate moving
> or
> > > splitting parts into libs/zblue profile by profile, where the
> boundary
> > > is
> > > technically clear.
> > >
> > > So yes, I think it is possible to modify the PR to let both stacks plus
> > > NimBLE work on NuttX without interfering with each other. I just think
> > > doing a full libs/zblue separation as the first step may be risky,
> > > especially for the lower-level profiles and audio-related paths.
> > >
> > > Does this direction sound acceptable to you?
> > >
> > > BR,
> > >
> > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 19:32写道：
> > >
> > > > Hi Anchao,
> > > >
> > > > Yes, I think having a complete BLE stack like zblue is a good idea.
> > > >
> > > > But we need to find a middle ground for correct integration.
> > > >
> > > > Let's do this: add zblue to libs/zglue and maintain a proper
> separation
> > > to
> > > > allow room for the existing BLE stack on NuttX to evolve.
> > > >
> > > > Just assuming that not updating/synchroning zblue with Zephyr's zblue
> > > will
> > > > be enough for them to become different entities seems incorrect.
> > > >
> > > > The amount of code is very large, so even after decades they will
> share
> > > > enough of their "DNA" that a virus will be able to infect both.
> > > >
> > > > Do you think it is possible to modify your PR to let both stacks (+
> > > NimBLE
> > > > userspace stack) work on NuttX without one interfering on the other?
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com>
> wrote:
> > > >
> > > > > Hi Alan,
> > > > >
> > > > >
> > > > >
> > > > > Thank you for the detailed analysis.
> > > > >
> > > > >
> > > > >
> > > > > I understand your concern. The current code structure is indeed
> still
> > > > very
> > > > >
> > > > > close to Zephyr's Bluetooth stack, and the compatibility layer is
> > > > currently
> > > > >
> > > > > quite thin. However, from the long-term technical direction, our
> > > > intention
> > > > > is
> > > > > not to keep doing long-term synchronization with Zephyr. Instead,
> we
> > > plan
> > > > > to
> > > > > quickly feed back the related issues and improvements to the NuttX
> > > > > community
> > > > > during the integration and evolution process.
> > > > >
> > > > >
> > > > >
> > > > > Regarding the naming concern, I think it is reasonable to call it
> > zblue
> > > > >
> > > > > temporarily, since the current implementation is still largely
> based
> > on
> > > > >
> > > > > Zephyr's Bluetooth stack. If the stack evolves later with a new
> code
> > > > > structure
> > > > > and clearer NuttX-specific architecture, we can further evaluate
> > > whether
> > > > a
> > > > >
> > > > > different name would be more appropriate at that time.
> > > > >
> > > > >
> > > > >
> > > > > Does that sound reasonable to you?
> > > > >
> > > > >
> > > > >
> > > > > BR,
> > > > >
> > > > >
> > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> > > > >
> > > > > > Hi Anchao,
> > > > > >
> > > > > > I used Claude to help compare the code and here are the reasons
> to
> > > call
> > > > > it
> > > > > > zblue instead of libs/bt:
> > > > > >
> > > > > > Almost all of this PR is Zephyr's Bluetooth stack
> > > > > > ("zblue"), reformatted to NuttX style. The part that doesn't come
> > > from
> > > > > > Zephyr is
> > > > > > a thin compatibility layer that makes the Zephyr kernel calls
> work
> > on
> > > > > > NuttX.
> > > > > >
> > > > > > I pulled all 539 new files (400,450 lines) and compared them
> > against
> > > > > > several
> > > > > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it
> > > matches
> > > > > > better
> > > > > > than Zephyr's current main branch. So the PR looks like a
> snapshot
> > of
> > > > > zblue
> > > > > > from the last few weeks.
> > > > > >
> > > > > > Results
> > > > > >
> > > > > > Function by function (7,716 functions):
> > > > > >
> > > > > > Class: Identical
> > > > > > Functions: 5,411 (70%)
> > > > > > Lines: 140,189
> > > > > > Meaning: Exactly the same code as Zephyr. Only indentation and
> > > braces
> > > > > > differ.
> > > > > > ────────────────────────────────────────
> > > > > > Class: Renames only
> > > > > > Functions: 1,515 (20%)
> > > > > > Lines: 60,863
> > > > > > Meaning: The only changes are API renames that recur across the
> > > whole
> > > > > PR:
> > > > > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> > > > > sys_slist_*→list_*,
> > > > > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post,
> > atomic_get→atomic_read
> > > > > > ────────────────────────────────────────
> > > > > > Class: Modified
> > > > > > Functions: 584 (8%)
> > > > > > Lines: 33,693
> > > > > > Meaning: Clearly the Zephyr function, plus some edits specific
> to
> > > > that
> > > > > > function
> > > > > > ────────────────────────────────────────
> > > > > > Class: Not from Zephyr
> > > > > > Functions: 206 (3%)
> > > > > > Lines: 2,734
> > > > > > Meaning: NuttX glue code
> > > > > >
> > > > > > Whole files, including headers:
> > > > > > - On average, 96.9% of each file's code also appears in its
> > Zephyr
> > > > > > counterpart.
> > > > > > - 434 of the 539 files are ≥90% the same as Zephyr; together
> they
> > > > hold
> > > > > > 375k of
> > > > > > the 400k lines.
> > > > > > - 75% of the comment text, including the Doxygen docs, is
> > > > word-for-word
> > > > > > Zephyr.
> > > > > >
> > > > > > What's actually new:
> > > > > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c,
> > > > mem_slab.c,
> > > > > > fs.c,
> > > > > > sections/defines.c, hci_driver.c), which provides k_work,
> > k_queue
> > > > and
> > > > > > similar
> > > > > > Zephyr calls on top of NuttX.
> > > > > > - Part of mm/net_buf.
> > > > > > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > > > > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt
> > defconfig.
> > > > > >
> > > > > >
> > > > > > So, only 3% of the code is new (this includes the code in sim:bt
> > that
> > > > > must
> > > > > > be new).
> > > > > >
> > > > > > So, reusing the zblue from Zephyr and calling it something else
> > isn't
> > > > > > right; it's like the zbus that Jorge brought from Zephyr, where
> > > calling
> > > > > it
> > > > > > NXBus doesn't seem appropriate.
> > > > > >
> > > > > > Besides that, as I said before using ZBlue as our official BT
> Stack
> > > > will
> > > > > > significantly increase the shared code between NuttX and Zephyr,
> > > which
> > > > > > could be dangerous.
> > > > > >
> > > > > > As I said, I not against adding ZBlue to NuttX, but at least make
> > it
> > > > > clear
> > > > > > that it is ZBlue and should be an alternative stack (like NimBLE)
> > not
> > > > the
> > > > > > official NuttX BLE Stack.
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > > On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi Alan,
> > > > > > >
> > > > > > > Thanks for the comments and suggestions.
> > > > > > >
> > > > > > > For the first stage, I would prefer to keep the Bluetooth host
> > > stack
> > > > > > > supported only in FLAT mode. Supporting Protected and Kernel
> > modes
> > > > > > requires
> > > > > > > a much deeper rework of the stack and its interfaces,
> especially
> > > > around
> > > > > > the
> > > > > > > boundary between kernel space and user space. I do not think it
> > is
> > > a
> > > > > good
> > > > > > > idea to introduce such large architectural changes in this
> first
> > > > step.
> > > > > > >
> > > > > > > Our current plan is to complete Protected/Kernel mode support
> in
> > a
> > > > > second
> > > > > > > stage, after the basic stack integration is reviewed and
> > > stabilized.
> > > > > This
> > > > > > > should make the initial review and integration much more
> > > manageable.
> > > > > > >
> > > > > > > Regarding the library name, I still prefer to use libs/libbt.
> > > > Although
> > > > > > the
> > > > > > > current code is based on Zephyr's zblue, the goal is to
> maintain
> > it
> > > > as
> > > > > an
> > > > > > > independent NuttX Bluetooth host stack going forward, rather
> than
> > > > > keeping
> > > > > > > it as a direct Zephyr fork forever. In that sense, I think
> libbt
> > > is a
> > > > > > > better long-term name.
> > > > > > >
> > > > > > > Also, the current NuttX Bluetooth profiles are not implemented
> in
> > > the
> > > > > > > kernel, and we do not plan to move the native NuttX Bluetooth
> > stack
> > > > > > > profiles into the kernel either. Once Protected/Kernel mode
> > support
> > > > is
> > > > > > > added for this stack in the future, this implementation is
> > expected
> > > > to
> > > > > > > replace the previous approach. For this reason, I think keeping
> > the
> > > > > stack
> > > > > > > under libbt is still more appropriate.
> > > > > > >
> > > > > > > About splitting the PR: this PR is already the result of
> > squashing
> > > > more
> > > > > > > than one hundred commits. Most of those commits are
> > > > compatibility-layer
> > > > > > > adjustments, coding style cleanup, and mechanical changes
> needed
> > to
> > > > > make
> > > > > > > the stack build in NuttX. Asking reviewers to review each of
> > those
> > > > > > commits
> > > > > > > separately would probably cost everyone more time.
> > > > > > >
> > > > > > > Splitting the full Bluetooth stack by profile is also not very
> > > > > practical
> > > > > > at
> > > > > > > the moment, because there are no dedicated maintainers for each
> > > > > > individual
> > > > > > > Bluetooth profile area in NuttX yet. Therefore, I think the
> > current
> > > > > form
> > > > > > is
> > > > > > > probably the most reasonable way to review and integrate the
> > stack
> > > > as a
> > > > > > > whole.
> > > > > > >
> > > > > > > One more update: I have removed all shell-related code from
> > > > > > > https://github.com/apache/nuttx/pull/20686. The plan is to
> move
> > > > those
> > > > > > > shell
> > > > > > > commands to apps later. With this change, the current Bluetooth
> > > stack
> > > > > no
> > > > > > > longer contains any user-space shell code, so I think this is
> > now a
> > > > > > better
> > > > > > > point for review.
> > > > > > >
> > > > > > > Best regards,
> > > > > > >
> > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > > > > > >
> > > > > > > > Hi An Chao,
> > > > > > > >
> > > > > > > > Isn't it possible to have a similar implementation that works
> > for
> > > > > FLAT,
> > > > > > > > Protected and Kernel modes?
> > > > > > > >
> > > > > > > > This way the maintenance will be easier. Only small
> > > kernel-specific
> > > > > > parts
> > > > > > > > will remain there (as Raiden and Xiang proposed).
> > > > > > > >
> > > > > > > > Suggestion: instead of naming it libs/libbt/, it would be
> > better
> > > to
> > > > > use
> > > > > > > > libs/zblue to make it clear that it is a zblue port from
> > Zephyr.
> > > > > > > >
> > > > > > > > Let's use libs/libbt only for NuttX-specific (native) code.
> > > > > > > >
> > > > > > > > And as I said, it is better to easily isolate the code that
> > came
> > > > from
> > > > > > > > Zephyr's zblue.
> > > > > > > >
> > > > > > > > This way the user could select the Bluetooth stack they want
> > > > without
> > > > > > > having
> > > > > > > > code from the other stack attached to it.
> > > > > > > >
> > > > > > > > Also I suggest you to break your PR into smaller PRs; a
> single
> > PR
> > > > > > > changing
> > > > > > > > more than 660K LoC is very massive.
> > > > > > > >
> > > > > > > > BR,
> > > > > > > >
> > > > > > > > Alan
> > > > > > > >
> > > > > > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <magicdcps@gmail.com
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Alan,
> > > > > > > > >
> > > > > > > > > Thank you for the thoughtful perspective and for engaging
> in
> > > the
> > > > > > > > > discussion.
> > > > > > > > >
> > > > > > > > > On security: we will maintain the Bluetooth stack ourselves
> > and
> > > > > take
> > > > > > > > > responsibility for tracking and fixing vulnerabilities. I'm
> > > also
> > > > > > > > confident
> > > > > > > > > that Xiaomi will contribute back on security issues given
> > their
> > > > > > ongoing
> > > > > > > > > investment in this codebase. This isn't a blind import —
> it's
> > > > code
> > > > > > that
> > > > > > > > has
> > > > > > > > > active, committed maintainers behind it.
> > > > > > > > >
> > > > > > > > > Regarding the history with Greg: you're right that we
> > discussed
> > > > > this
> > > > > > > > years
> > > > > > > > > ago. But there's an important distinction — that earlier
> > > proposal
> > > > > > > placed
> > > > > > > > > the stack entirely in userspace. It did nothing to
> strengthen
> > > > > NuttX's
> > > > > > > > > kernel-level Bluetooth support. That's precisely why I'm
> back
> > > > now,
> > > > > > > > > providing a kernel implementation this time around, which
> is
> > > > what I
> > > > > > > > > committed to back then. Feel free to search the mailing
> list
> > > > > > archives —
> > > > > > > > the
> > > > > > > > > NuttX native Bluetooth stack will evolve from this baseline
> > > going
> > > > > > > > forward.
> > > > > > > > >
> > > > > > > > > This implementation does not affect existing Bluetooth
> stacks
> > > in
> > > > > any
> > > > > > > way.
> > > > > > > > > Users can still choose NimBLE, the current NuttX BLE stack,
> > or
> > > > any
> > > > > > > other
> > > > > > > > > solution. This is an additional option, not a replacement.
> > The
> > > > goal
> > > > > > is
> > > > > > > to
> > > > > > > > > give NuttX users more choices, not fewer.
> > > > > > > > >
> > > > > > > > > One more update: I just spoke with Xiaoxiang and we've
> > reached
> > > > some
> > > > > > > > common
> > > > > > > > > ground. He's no longer opposed to the current stack
> > > > implementation
> > > > > > and
> > > > > > > > > agrees that the focus should be on proper structuring.
> Here's
> > > the
> > > > > > plan
> > > > > > > > > going forward:
> > > > > > > > >
> > > > > > > > > 1. Unused shell code will be moved out of the stack and
> > into
> > > > > > apps/,
> > > > > > > > > running entirely in userspace.
> > > > > > > > > 2. Bluetooth profiles will be migrated to libs/libbt/,
> > where
> > > > > we'll
> > > > > > > > > provide two OS API backends: a POSIX API implementation
> > (for
> > > > > > > > > kernel/protected builds) and a NuttX kernel API
> > > implementation
> > > > > > (for
> > > > > > > > flat
> > > > > > > > > mode).
> > > > > > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > > > > > >
> > > > > > > > > This should address the architectural concerns while
> > preserving
> > > > the
> > > > > > > > > performance path for flat-mode deployments.
> > > > > > > > >
> > > > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > > > > > > >
> > > > > > > > > > Hi An Chao,
> > > > > > > > > >
> > > > > > > > > > Thank you for trying to improve the NuttX Bluetooth
> > support.
> > > > And
> > > > > > > thank
> > > > > > > > > you
> > > > > > > > > > to bring this discussion here to let more people give
> their
> > > > > > opinion.
> > > > > > > > > >
> > > > > > > > > > I think most of the concerns raised by Xiang and Raiden
> > > > (Mateusz)
> > > > > > are
> > > > > > > > > > important and need to be addressed.
> > > > > > > > > >
> > > > > > > > > > As I said at GitHub PR I think a main concern here is
> using
> > > the
> > > > > > same
> > > > > > > > > > Bluetooth stack used on Zephyr, not because it is a bad
> > stack
> > > > (of
> > > > > > > > course
> > > > > > > > > it
> > > > > > > > > > is not, it was developed by experts on Bluetooth area),
> but
> > > > > because
> > > > > > > we
> > > > > > > > > are
> > > > > > > > > > adding the same surface area of attack from Zephyr on
> > NuttX.
> > > > > > > > > >
> > > > > > > > > > That means any security vulnerability affecting Zephyr
> BLE
> > > > stack
> > > > > > will
> > > > > > > > > > affect NuttX. It remove the protection that a companies
> > could
> > > > > > obtain
> > > > > > > > when
> > > > > > > > > > using different RTOSs.
> > > > > > > > > >
> > > > > > > > > > Also, if my memory still serving me, I think Xiaomi team
> > (you
> > > > was
> > > > > > > there
> > > > > > > > > at
> > > > > > > > > > that time) already tried to submit their initial port of
> > > Zephyr
> > > > > BLE
> > > > > > > > stack
> > > > > > > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > > > > > > >
> > > > > > > > > > His suggestion was to improve our BLE stack, that in fact
> > has
> > > > the
> > > > > > > same
> > > > > > > > > > origin of the Zephyr BLE stack (both came from a BLE
> stack
> > > from
> > > > > > Intel
> > > > > > > > > > released as BSD license at that time).
> > > > > > > > > >
> > > > > > > > > > I'm not against including the Zephyr BLE stack, but it
> > should
> > > > be
> > > > > > > > > > selectable. Ideally the user should select if he/she
> wants
> > to
> > > > use
> > > > > > > > NimBLE,
> > > > > > > > > > Zephyr or NuttX native BLE stack.
> > > > > > > > > >
> > > > > > > > > > BR,
> > > > > > > > > >
> > > > > > > > > > Alan
> > > > > > > > > >
> > > > > > > > > > On Friday, October 16, 2026, chao an <
> magicdcps@gmail.com>
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi, Tomek,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the thoughtful input and the FreeBSD
> > references
> > > —
> > > > > > those
> > > > > > > > are
> > > > > > > > > > very
> > > > > > > > > > > relevant to where we're heading.
> > > > > > > > > > >
> > > > > > > > > > > Just to set the context: NuttX's current Bluetooth
> stack
> > > only
> > > > > > > > supports
> > > > > > > > > > BLE.
> > > > > > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are
> all
> > > > > > missing.
> > > > > > > > This
> > > > > > > > > > is
> > > > > > > > > > > exactly why we want to bring a more complete Bluetooth
> > > stack
> > > > to
> > > > > > > > NuttX —
> > > > > > > > > > to
> > > > > > > > > > > catch up with what mainstream RTOS communities already
> > > offer.
> > > > > > > > > > >
> > > > > > > > > > > I actually agree with the FreeBSD/Apple architecture
> you
> > > > > > > referenced.
> > > > > > > > > Our
> > > > > > > > > > > end-state plan is similar: the L2CAP and HCI layers
> will
> > > live
> > > > > in
> > > > > > > the
> > > > > > > > > > > kernel, and a bluetoothd-style daemon will be
> implemented
> > > in
> > > > > > libc,
> > > > > > > > > > managing
> > > > > > > > > > > profiles and higher-level protocols. This gives us a
> > clean
> > > > > > > > separation —
> > > > > > > > > > > transport in the kernel, policy and profiles in
> > userspace —
> > > > > much
> > > > > > > like
> > > > > > > > > how
> > > > > > > > > > > FreeBSD's ng_hci / hccontrol split works. The current
> PR
> > is
> > > > > > Phase 1
> > > > > > > > of
> > > > > > > > > > > getting there incrementally.
> > > > > > > > > > >
> > > > > > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > > > > > > >
> > > > > > > > > > > > Thank you An Chao for this proposition, work, and
> > > > discussion
> > > > > > :-)
> > > > > > > > > > > >
> > > > > > > > > > > > For sure it would be nice to have a BT stack with
> more
> > > > > > features!
> > > > > > > > The
> > > > > > > > > > > > BT has known issue of having different
> implementations
> > of
> > > > the
> > > > > > > stack
> > > > > > > > > on
> > > > > > > > > > > > different RTOS / OS / platforms, which is a known
> > issue,
> > > > and
> > > > > > > kinda
> > > > > > > > > > > > mess because there is no common standard / approach /
> > > > > > > > implementation,
> > > > > > > > > > > > unfortunately around something that is supposed to be
> > > based
> > > > > on
> > > > > > a
> > > > > > > > > > > > common standard.
> > > > > > > > > > > >
> > > > > > > > > > > > Having common BT stack with other popular RTOS may
> make
> > > > > > > portability
> > > > > > > > > > > > easier and developers move to NuttX in some cases.
> > > > > > > > > > > >
> > > > > > > > > > > > I understand that we are talking about this solution?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > > > > > connectivity/bluetooth/index.html
> > > > > > > > > > > >
> > > > > > > > > > > > In a perfect situation we would want to have modular
> > > > > > > implementation
> > > > > > > > > in
> > > > > > > > > > > > nuttx-apps just like nimble. This is pointed out by
> > > Xiang,
> > > > > > > Raiden,
> > > > > > > > > and
> > > > > > > > > > > > Alin already. But I understand some things may be
> hard
> > to
> > > > > > > implement
> > > > > > > > > > > > that way. I will follow the consensus here when
> ready,
> > I
> > > > have
> > > > > > no
> > > > > > > > > > > > strong opinion here, except any BT stack I touched
> > before
> > > > > was a
> > > > > > > > mess
> > > > > > > > > > > > and I hope we can work out at least something decent
> > :-P
> > > > > > > > > > > >
> > > > > > > > > > > > A bit offtopic but for kernel build we can take a
> look
> > at
> > > > > quite
> > > > > > > old
> > > > > > > > > > > > Bluetooth implementation on FreeBSD, where radio is
> > > > provided
> > > > > by
> > > > > > > > > ng_ubt
> > > > > > > > > > > > (lower half in out case), then upper half uses
> standard
> > > > HCI.
> > > > > > > Maybe
> > > > > > > > > > > > something like this is possible in NuttX?
> > > > > > > > > > > >
> > > > > > > > > > > > 1.
> https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > > > > > 3.
> https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > > > > > 4.
> > > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > > > > > 5.
> > > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > > > > > >
> > > > > > > > > > > > Here is a quick overview article on the Bluetooth
> > > > > > implementation
> > > > > > > in
> > > > > > > > > > > > FreeBSD and Apple:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > > > > > >
> > > > > > > > > > > > Again it will be very nice to have fully featured BT
> > > stack
> > > > in
> > > > > > > NuttX
> > > > > > > > > > > > and I hope we can sort out the best possible porting
> > > > > > > implementation
> > > > > > > > > > > > :-)
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > > > > > jerpelea@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > thanks Xiao and Raiden for your technical opinions
> > > which
> > > > I
> > > > > > also
> > > > > > > > > share
> > > > > > > > > > > so
> > > > > > > > > > > > I
> > > > > > > > > > > > > will not iterate them again.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > > > > > it should be splitted between nuttx and apps-repos
> > and
> > > > use
> > > > > > > POSIX
> > > > > > > > > > > > > implementation as much as possible. We are focused
> on
> > > > > > standards
> > > > > > > > and
> > > > > > > > > > > > > compatibility.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Another concern is the license which does not match
> > our
> > > > ASF
> > > > > > one
> > > > > > > > and
> > > > > > > > > > > does
> > > > > > > > > > > > > not include any LICENSE file additions to clarify
> the
> > > > > > compiance
> > > > > > > > > > aspect
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best regards
> > > > > > > > > > > > > Alin J
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > > > > > xiaoxiang781216@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > > > > > magicdcps@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So the real reason you've been objecting to my
> > > > proposal
> > > > > > is
> > > > > > > > that
> > > > > > > > > > > your
> > > > > > > > > > > > team
> > > > > > > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If you can give me a clear timeline for when
> your
> > > > > > > > > implementation
> > > > > > > > > > > > will be
> > > > > > > > > > > > > > > submitted upstream, I'm happy to withdraw my PR
> > and
> > > > let
> > > > > > > your
> > > > > > > > > code
> > > > > > > > > > > > serve
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > the baseline. I'm not here to fight over
> > ownership
> > > of
> > > > > the
> > > > > > > > > > Bluetooth
> > > > > > > > > > > > > > stack.
> > > > > > > > > > > > > > > My only motivation is that NuttX's lack of a
> > > capable
> > > > > > > > Bluetooth
> > > > > > > > > > > stack
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > driving every developer toward Zephyr — and as
> a
> > > PMC
> > > > > > > member,
> > > > > > > > I
> > > > > > > > > > > think
> > > > > > > > > > > > you
> > > > > > > > > > > > > > > should be asking yourselves why this gap has
> > > remained
> > > > > > > > unfilled
> > > > > > > > > > for
> > > > > > > > > > > so
> > > > > > > > > > > > > > long.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > I object to landing the whole bluetooth stack
> into
> > > > kernel
> > > > > > > space
> > > > > > > > > > > > directly
> > > > > > > > > > > > > > either yours and ours .
> > > > > > > > > > > > > > This is the same feeling from raiden00pl too,
> let's
> > > see
> > > > > > other
> > > > > > > > > > > people's
> > > > > > > > > > > > > > opinions here.
> > > > > > > > > > > > > > But it's fine for me to host the whole code in
> > > > > > nuttx-apps.git
> > > > > > > > and
> > > > > > > > > > > > refactor
> > > > > > > > > > > > > > components to kernel
> > > > > > > > > > > > > > space step by step.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As for the current PR, I'll remove the shell
> > > > components
> > > > > > > from
> > > > > > > > > the
> > > > > > > > > > > > stack
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > move them into apps/ where they belong. The
> base
> > > > > profiles
> > > > > > > > > (A2DP,
> > > > > > > > > > > BLE)
> > > > > > > > > > > > > > will
> > > > > > > > > > > > > > > stay in libc —
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The architecture is wrong to host any bluetooth
> > > > profile
> > > > > in
> > > > > > > > libc.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > in flat build mode this gives a significant
> > > performance
> > > > > > > > > > > > > > > boost to the overall stack, which is the
> primary
> > > > > > deployment
> > > > > > > > > model
> > > > > > > > > > > for
> > > > > > > > > > > > > > most
> > > > > > > > > > > > > > > NuttX devices.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > Performance should remain the same whether the
> base
> > > > > profile
> > > > > > > is
> > > > > > > > > > hosted
> > > > > > > > > > > > in
> > > > > > > > > > > > > > libc or apps,
> > > > > > > > > > > > > > could you point out any technical reason which
> > > impacts
> > > > > the
> > > > > > > > > > > performance
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the flat mode?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A few additional data points regarding our
> > > timeline:
> > > > > our
> > > > > > > > > product
> > > > > > > > > > is
> > > > > > > > > > > > > > > scheduled for release in December, and
> Bluetooth
> > > SIG
> > > > > > > > > > certification
> > > > > > > > > > > is
> > > > > > > > > > > > > > > already in progress — we expect to receive it
> > > around
> > > > > > > > November.
> > > > > > > > > If
> > > > > > > > > > > the
> > > > > > > > > > > > > > > baseline were to switch to your team's stack
> with
> > > its
> > > > > > > > different
> > > > > > > > > > > > > > > architecture, that certification cycle would
> need
> > > to
> > > > be
> > > > > > > > > repeated,
> > > > > > > > > > > > which
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Xiang Xiao <xi...@gmail.com>
> > > > 于2026年10月16日周五
> > > > > > > > 15:08写道：
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > > > > > magicdcps@gmail.com
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Regarding your point about the NimBLE port
> > > using
> > > > > the
> > > > > > > > POSIX
> > > > > > > > > > API
> > > > > > > > > > > —
> > > > > > > > > > > > yes,
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > uses POSIX, but there are real issues with
> > the
> > > > > > current
> > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > go beyond just kernel/protected mode
> support.
> > > > > > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real
> > > > critical
> > > > > > > > section
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This is a mutex, not a critical section. It
> > > does
> > > > > not
> > > > > > > > > disable
> > > > > > > > > > > > > > interrupts
> > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > preemption — an ISR can still fire and
> > corrupt
> > > > data
> > > > > > > that
> > > > > > > > > the
> > > > > > > > > > > > > > "critical
> > > > > > > > > > > > > > > > > section" was supposed to protect. On top of
> > > that,
> > > > > > > using a
> > > > > > > > > > mutex
> > > > > > > > > > > > opens
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > door to ABBA deadlocks when combined with
> any
> > > > other
> > > > > > > lock
> > > > > > > > > held
> > > > > > > > > > > > inside
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > critical region:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > - Thread A: enter_critical →
> > lock(s_mutex) →
> > > > try
> > > > > > > > > > lock(mutex
> > > > > > > > > > > > M) ←
> > > > > > > > > > > > > > > > blocked
> > > > > > > > > > > > > > > > > by B
> > > > > > > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > > > > > > lock(s_mutex) ←
> > > > > > > > > > > > blocked by
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Compare this with the FreeRTOS port, which
> > > > > correctly
> > > > > > > uses
> > > > > > > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical()
> > > (i.e.,
> > > > > > > > actually
> > > > > > > > > > > > disabling
> > > > > > > > > > > > > > > > > scheduling/preemption). The current NuttX
> > port
> > > > > simply
> > > > > > > > does
> > > > > > > > > > not
> > > > > > > > > > > > meet
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > semantic contract that the NimBLE stack
> > expects
> > > > > from
> > > > > > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > > > > > 2. Time subsystem uses clock_gettime
> instead
> > of
> > > > > > kernel
> > > > > > > > tick
> > > > > > > > > > > APIs
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > > > > > ...),
> > > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > involves a syscall and floating-point
> > > arithmetic
> > > > on
> > > > > > > every
> > > > > > > > > > call.
> > > > > > > > > > > > In a
> > > > > > > > > > > > > > > BLE
> > > > > > > > > > > > > > > > > stack where timestamps and timing are on
> the
> > > hot
> > > > > > path,
> > > > > > > > this
> > > > > > > > > > > adds
> > > > > > > > > > > > > > > > measurable
> > > > > > > > > > > > > > > > > overhead compared to accessing the kernel
> > tick
> > > > > > counter
> > > > > > > > > > > directly.
> > > > > > > > > > > > > > > > > 3. Others are already using the kernel
> > > approach —
> > > > > and
> > > > > > > for
> > > > > > > > > > good
> > > > > > > > > > > > reason
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth
> stack
> > > > > (zblue)
> > > > > > > for
> > > > > > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX
> > for
> > > > the
> > > > > > > > > > > > > > performance-critical
> > > > > > > > > > > > > > > > > paths:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This isn't an academic exercise — it's a
> > > > production
> > > > > > > > choice.
> > > > > > > > > > > They
> > > > > > > > > > > > > > > > recognized
> > > > > > > > > > > > > > > > > that a BLE stack needs tight integration
> with
> > > the
> > > > > OS
> > > > > > > > timer
> > > > > > > > > > > > subsystem,
> > > > > > > > > > > > > > > > > direct access to critical section
> primitives,
> > > and
> > > > > > > > efficient
> > > > > > > > > > > event
> > > > > > > > > > > > > > > > delivery,
> > > > > > > > > > > > > > > > > none of which POSIX provides well in this
> > > > context.
> > > > > > > > > > > > > > > > > My question
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > If other organizations are already using a
> > more
> > > > > > > > performant,
> > > > > > > > > > > > > > > > architecturally
> > > > > > > > > > > > > > > > > correct kernel-level integration for their
> > BLE
> > > > > stacks
> > > > > > > on
> > > > > > > > > > NuttX,
> > > > > > > > > > > > why
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > we be told that we must use the slower,
> less
> > > > > correct
> > > > > > > > POSIX
> > > > > > > > > > > path?
> > > > > > > > > > > > > > > NuttX's
> > > > > > > > > > > > > > > > > POSIX compliance is valuable, but it
> > shouldn't
> > > > come
> > > > > > at
> > > > > > > > the
> > > > > > > > > > cost
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > > shipping
> > > > > > > > > > > > > > > > > a BLE stack with a broken critical section
> > > > > primitive.
> > > > > > > > There
> > > > > > > > > > > > should be
> > > > > > > > > > > > > > > > room
> > > > > > > > > > > > > > > > > for both approaches, and the decision
> should
> > be
> > > > > > driven
> > > > > > > by
> > > > > > > > > > > > technical
> > > > > > > > > > > > > > > > merit,
> > > > > > > > > > > > > > > > > not by treating POSIX as the only
> acceptable
> > > > > answer.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't object to moving the key bluetooth
> > stack
> > > to
> > > > > > > kernel
> > > > > > > > > > space
> > > > > > > > > > > > like
> > > > > > > > > > > > > > how
> > > > > > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > > > > > > https://github.com/apache/nuttx/pull/20686
> is
> > > far
> > > > to
> > > > > > > move
> > > > > > > > > > > entirely
> > > > > > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > > > > > If I low my quality bar, I have requested my
> > > > teammate
> > > > > > to
> > > > > > > > > > upstream
> > > > > > > > > > > > our
> > > > > > > > > > > > > > > > implementation:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > > since much work needs to be done before it
> can
> > > > > achieve
> > > > > > > the
> > > > > > > > > > > quality
> > > > > > > > > > > > > > > > upstream.
> > > > > > > > > > > > > > > > BTW, many zephyr class BT features are
> > developed
> > > by
> > > > > my
> > > > > > > team
> > > > > > > > > and
> > > > > > > > > > > > > > upstream
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > > > > > If considering the quality, our version is
> much
> > > > > better
> > > > > > > > since:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2
> > certification
> > > > at
> > > > > > > > 2026.06
> > > > > > > > > > > > > > > > 3. Product on wear device by end of this
> > year
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alan,
Thanks for the suggestion and for offering to help with testing!
I agree with your point. It is better to avoid introducing net/bt as an
intermediate layout if we already know it will be moved later, since that
would create unnecessary churn and could become a breaking change after
merge.
I have updated the patch accordingly:
- Moved the Bluetooth host stack build integration out of net/
- Kept the implementation under libs/zblue
- Added libs/zblue as a standalone NuttX library, similar to other libs/*
components
- Moved the Kconfig entry under the top-level Wireless Support menu
- Registered libzblue through the standard Make library target flow
- Reworked the Make.defs paths to use TOPDIR-based paths instead of
relative
../libs/zblue paths
I also re-tested the integration with the sim:bt configuration, and the
native
Make build passes. I re-ran nxstyle and codespell as well, and both are
clean.
For the Kconfig selection, I agree that more explicit options will make it
easier for users to enable only the parts they need. I will continue
refining
that so the stack is not exposed as one overly broad switch.
Thanks again for the review and for working on the BT side too. Any
additional
testing from your side would be very welcome.
BR,
Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 20:28写道：
> Hi Anchao,
>
> Sounds good!
>
> Yes, I suggest going with more explicitly selection in the Kconfig so users
> can select what they want more easily.
>
> Regarding "net/bt," there is not a more permanent solution than a temporary
> one. This is a reason to avoid it.
>
> I understand that you tested the integration this way and agreed to change
> it to libs/zblue later, but I strongly recommend making that change before
> merging.
>
> Adding something that will probably change will result in a "breaking
> change" later, which we are trying to avoid on NuttX.
>
> So the best moment to change it is before it gets merged. If you need help
> testing, I can assist here. I'm already working on BT (first fixing small
> issues).
>
> BR,
>
> Alan
>
> On Thu, Oct 22, 2026 at 8:55 AM chao an <ma...@gmail.com> wrote:
>
> > Hi Alan,
> >
> > Yes, I agree that we need to find a middle ground and make sure the
> > integration does not block the existing Bluetooth solutions in NuttX.
> >
> > From the current implementation, I don't think this zblue-based stack
> > conflicts with NimBLE or with the existing in-tree BLE stack. They can be
> > selected independently through Kconfig. For example:
> >
> > - CONFIG_BT Enables the new zblue-based host stack currently added by
> > this PR.
> > - CONFIG_WIRELESS_BLUETOOTH
> > - CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE stack
> > under wireless/bluetooth.
> > - CONFIG_NIMBLE Enables the userspace NimBLE stack when that stack is
> > used from apps.
> >
> > The lower-level Bluetooth controller / transport drivers are also
> separate,
> > for example:
> >
> > - CONFIG_BLUETOOTH_UART
> > - CONFIG_BLUETOOTH_RPMSG
> > - CONFIG_BLUETOOTH_NULL
> >
> > So I think it is possible to make the three options coexist on NuttX, as
> > long as we keep the host-stack selection separated and avoid enabling two
> > host stacks for the same controller path at the same time. If needed, we
> > can also make this more explicit by adding a Kconfig choice or mutual
> > exclusion between the host stacks.
> >
> > Regarding the location, I understand your point about libs/zblue.
> However,
> > for the initial version, I still think keeping the full stack under
> net/bt
> > is the safer integration path.
> >
> > The reason is that splitting it into libs/zblue is not only a directory
> > rename. To do that correctly, we need to isolate each profile and data
> path
> > according to its own characteristics. Some profiles are not just pure
> > userspace library logic. For example, SCO and LE Audio / ISO have
> > lower-level data paths. On Linux, part of this kind of traffic is handled
> > or forwarded by the kernel side. So if we move everything to libs/zblue
> too
> > early, we may create an artificial boundary that is not correct for those
> > lower-level profiles.
> >
> > My suggestion is:
> >
> > 1. Keep the initial version integrated under net/bt, so the
> controller,
> > HCI, L2CAP, ISO/SCO and profile paths can work correctly first.
> > 2. Make the stack name clear as zblue if the community prefers that,
> so
> > it is not presented as replacing the existing NuttX BLE stack.
> > 3. Keep the Kconfig separation so users can choose between:
> > - zblue-based stack,
> > - existing NuttX BLE stack,
> > - NimBLE userspace stack.
> > 4. After the initial integration is stable, we can evaluate moving or
> > splitting parts into libs/zblue profile by profile, where the boundary
> > is
> > technically clear.
> >
> > So yes, I think it is possible to modify the PR to let both stacks plus
> > NimBLE work on NuttX without interfering with each other. I just think
> > doing a full libs/zblue separation as the first step may be risky,
> > especially for the lower-level profiles and audio-related paths.
> >
> > Does this direction sound acceptable to you?
> >
> > BR,
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 19:32写道：
> >
> > > Hi Anchao,
> > >
> > > Yes, I think having a complete BLE stack like zblue is a good idea.
> > >
> > > But we need to find a middle ground for correct integration.
> > >
> > > Let's do this: add zblue to libs/zglue and maintain a proper separation
> > to
> > > allow room for the existing BLE stack on NuttX to evolve.
> > >
> > > Just assuming that not updating/synchroning zblue with Zephyr's zblue
> > will
> > > be enough for them to become different entities seems incorrect.
> > >
> > > The amount of code is very large, so even after decades they will share
> > > enough of their "DNA" that a virus will be able to infect both.
> > >
> > > Do you think it is possible to modify your PR to let both stacks (+
> > NimBLE
> > > userspace stack) work on NuttX without one interfering on the other?
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi Alan,
> > > >
> > > >
> > > >
> > > > Thank you for the detailed analysis.
> > > >
> > > >
> > > >
> > > > I understand your concern. The current code structure is indeed still
> > > very
> > > >
> > > > close to Zephyr's Bluetooth stack, and the compatibility layer is
> > > currently
> > > >
> > > > quite thin. However, from the long-term technical direction, our
> > > intention
> > > > is
> > > > not to keep doing long-term synchronization with Zephyr. Instead, we
> > plan
> > > > to
> > > > quickly feed back the related issues and improvements to the NuttX
> > > > community
> > > > during the integration and evolution process.
> > > >
> > > >
> > > >
> > > > Regarding the naming concern, I think it is reasonable to call it
> zblue
> > > >
> > > > temporarily, since the current implementation is still largely based
> on
> > > >
> > > > Zephyr's Bluetooth stack. If the stack evolves later with a new code
> > > > structure
> > > > and clearer NuttX-specific architecture, we can further evaluate
> > whether
> > > a
> > > >
> > > > different name would be more appropriate at that time.
> > > >
> > > >
> > > >
> > > > Does that sound reasonable to you?
> > > >
> > > >
> > > >
> > > > BR,
> > > >
> > > >
> > > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> > > >
> > > > > Hi Anchao,
> > > > >
> > > > > I used Claude to help compare the code and here are the reasons to
> > call
> > > > it
> > > > > zblue instead of libs/bt:
> > > > >
> > > > > Almost all of this PR is Zephyr's Bluetooth stack
> > > > > ("zblue"), reformatted to NuttX style. The part that doesn't come
> > from
> > > > > Zephyr is
> > > > > a thin compatibility layer that makes the Zephyr kernel calls work
> on
> > > > > NuttX.
> > > > >
> > > > > I pulled all 539 new files (400,450 lines) and compared them
> against
> > > > > several
> > > > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it
> > matches
> > > > > better
> > > > > than Zephyr's current main branch. So the PR looks like a snapshot
> of
> > > > zblue
> > > > > from the last few weeks.
> > > > >
> > > > > Results
> > > > >
> > > > > Function by function (7,716 functions):
> > > > >
> > > > > Class: Identical
> > > > > Functions: 5,411 (70%)
> > > > > Lines: 140,189
> > > > > Meaning: Exactly the same code as Zephyr. Only indentation and
> > braces
> > > > > differ.
> > > > > ────────────────────────────────────────
> > > > > Class: Renames only
> > > > > Functions: 1,515 (20%)
> > > > > Lines: 60,863
> > > > > Meaning: The only changes are API renames that recur across the
> > whole
> > > > PR:
> > > > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> > > > sys_slist_*→list_*,
> > > > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post,
> atomic_get→atomic_read
> > > > > ────────────────────────────────────────
> > > > > Class: Modified
> > > > > Functions: 584 (8%)
> > > > > Lines: 33,693
> > > > > Meaning: Clearly the Zephyr function, plus some edits specific to
> > > that
> > > > > function
> > > > > ────────────────────────────────────────
> > > > > Class: Not from Zephyr
> > > > > Functions: 206 (3%)
> > > > > Lines: 2,734
> > > > > Meaning: NuttX glue code
> > > > >
> > > > > Whole files, including headers:
> > > > > - On average, 96.9% of each file's code also appears in its
> Zephyr
> > > > > counterpart.
> > > > > - 434 of the 539 files are ≥90% the same as Zephyr; together they
> > > hold
> > > > > 375k of
> > > > > the 400k lines.
> > > > > - 75% of the comment text, including the Doxygen docs, is
> > > word-for-word
> > > > > Zephyr.
> > > > >
> > > > > What's actually new:
> > > > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c,
> > > mem_slab.c,
> > > > > fs.c,
> > > > > sections/defines.c, hci_driver.c), which provides k_work,
> k_queue
> > > and
> > > > > similar
> > > > > Zephyr calls on top of NuttX.
> > > > > - Part of mm/net_buf.
> > > > > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > > > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt
> defconfig.
> > > > >
> > > > >
> > > > > So, only 3% of the code is new (this includes the code in sim:bt
> that
> > > > must
> > > > > be new).
> > > > >
> > > > > So, reusing the zblue from Zephyr and calling it something else
> isn't
> > > > > right; it's like the zbus that Jorge brought from Zephyr, where
> > calling
> > > > it
> > > > > NXBus doesn't seem appropriate.
> > > > >
> > > > > Besides that, as I said before using ZBlue as our official BT Stack
> > > will
> > > > > significantly increase the shared code between NuttX and Zephyr,
> > which
> > > > > could be dangerous.
> > > > >
> > > > > As I said, I not against adding ZBlue to NuttX, but at least make
> it
> > > > clear
> > > > > that it is ZBlue and should be an alternative stack (like NimBLE)
> not
> > > the
> > > > > official NuttX BLE Stack.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > > Thanks for the comments and suggestions.
> > > > > >
> > > > > > For the first stage, I would prefer to keep the Bluetooth host
> > stack
> > > > > > supported only in FLAT mode. Supporting Protected and Kernel
> modes
> > > > > requires
> > > > > > a much deeper rework of the stack and its interfaces, especially
> > > around
> > > > > the
> > > > > > boundary between kernel space and user space. I do not think it
> is
> > a
> > > > good
> > > > > > idea to introduce such large architectural changes in this first
> > > step.
> > > > > >
> > > > > > Our current plan is to complete Protected/Kernel mode support in
> a
> > > > second
> > > > > > stage, after the basic stack integration is reviewed and
> > stabilized.
> > > > This
> > > > > > should make the initial review and integration much more
> > manageable.
> > > > > >
> > > > > > Regarding the library name, I still prefer to use libs/libbt.
> > > Although
> > > > > the
> > > > > > current code is based on Zephyr's zblue, the goal is to maintain
> it
> > > as
> > > > an
> > > > > > independent NuttX Bluetooth host stack going forward, rather than
> > > > keeping
> > > > > > it as a direct Zephyr fork forever. In that sense, I think libbt
> > is a
> > > > > > better long-term name.
> > > > > >
> > > > > > Also, the current NuttX Bluetooth profiles are not implemented in
> > the
> > > > > > kernel, and we do not plan to move the native NuttX Bluetooth
> stack
> > > > > > profiles into the kernel either. Once Protected/Kernel mode
> support
> > > is
> > > > > > added for this stack in the future, this implementation is
> expected
> > > to
> > > > > > replace the previous approach. For this reason, I think keeping
> the
> > > > stack
> > > > > > under libbt is still more appropriate.
> > > > > >
> > > > > > About splitting the PR: this PR is already the result of
> squashing
> > > more
> > > > > > than one hundred commits. Most of those commits are
> > > compatibility-layer
> > > > > > adjustments, coding style cleanup, and mechanical changes needed
> to
> > > > make
> > > > > > the stack build in NuttX. Asking reviewers to review each of
> those
> > > > > commits
> > > > > > separately would probably cost everyone more time.
> > > > > >
> > > > > > Splitting the full Bluetooth stack by profile is also not very
> > > > practical
> > > > > at
> > > > > > the moment, because there are no dedicated maintainers for each
> > > > > individual
> > > > > > Bluetooth profile area in NuttX yet. Therefore, I think the
> current
> > > > form
> > > > > is
> > > > > > probably the most reasonable way to review and integrate the
> stack
> > > as a
> > > > > > whole.
> > > > > >
> > > > > > One more update: I have removed all shell-related code from
> > > > > > https://github.com/apache/nuttx/pull/20686. The plan is to move
> > > those
> > > > > > shell
> > > > > > commands to apps later. With this change, the current Bluetooth
> > stack
> > > > no
> > > > > > longer contains any user-space shell code, so I think this is
> now a
> > > > > better
> > > > > > point for review.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > > > > >
> > > > > > > Hi An Chao,
> > > > > > >
> > > > > > > Isn't it possible to have a similar implementation that works
> for
> > > > FLAT,
> > > > > > > Protected and Kernel modes?
> > > > > > >
> > > > > > > This way the maintenance will be easier. Only small
> > kernel-specific
> > > > > parts
> > > > > > > will remain there (as Raiden and Xiang proposed).
> > > > > > >
> > > > > > > Suggestion: instead of naming it libs/libbt/, it would be
> better
> > to
> > > > use
> > > > > > > libs/zblue to make it clear that it is a zblue port from
> Zephyr.
> > > > > > >
> > > > > > > Let's use libs/libbt only for NuttX-specific (native) code.
> > > > > > >
> > > > > > > And as I said, it is better to easily isolate the code that
> came
> > > from
> > > > > > > Zephyr's zblue.
> > > > > > >
> > > > > > > This way the user could select the Bluetooth stack they want
> > > without
> > > > > > having
> > > > > > > code from the other stack attached to it.
> > > > > > >
> > > > > > > Also I suggest you to break your PR into smaller PRs; a single
> PR
> > > > > > changing
> > > > > > > more than 660K LoC is very massive.
> > > > > > >
> > > > > > > BR,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > > Hi Alan,
> > > > > > > >
> > > > > > > > Thank you for the thoughtful perspective and for engaging in
> > the
> > > > > > > > discussion.
> > > > > > > >
> > > > > > > > On security: we will maintain the Bluetooth stack ourselves
> and
> > > > take
> > > > > > > > responsibility for tracking and fixing vulnerabilities. I'm
> > also
> > > > > > > confident
> > > > > > > > that Xiaomi will contribute back on security issues given
> their
> > > > > ongoing
> > > > > > > > investment in this codebase. This isn't a blind import — it's
> > > code
> > > > > that
> > > > > > > has
> > > > > > > > active, committed maintainers behind it.
> > > > > > > >
> > > > > > > > Regarding the history with Greg: you're right that we
> discussed
> > > > this
> > > > > > > years
> > > > > > > > ago. But there's an important distinction — that earlier
> > proposal
> > > > > > placed
> > > > > > > > the stack entirely in userspace. It did nothing to strengthen
> > > > NuttX's
> > > > > > > > kernel-level Bluetooth support. That's precisely why I'm back
> > > now,
> > > > > > > > providing a kernel implementation this time around, which is
> > > what I
> > > > > > > > committed to back then. Feel free to search the mailing list
> > > > > archives —
> > > > > > > the
> > > > > > > > NuttX native Bluetooth stack will evolve from this baseline
> > going
> > > > > > > forward.
> > > > > > > >
> > > > > > > > This implementation does not affect existing Bluetooth stacks
> > in
> > > > any
> > > > > > way.
> > > > > > > > Users can still choose NimBLE, the current NuttX BLE stack,
> or
> > > any
> > > > > > other
> > > > > > > > solution. This is an additional option, not a replacement.
> The
> > > goal
> > > > > is
> > > > > > to
> > > > > > > > give NuttX users more choices, not fewer.
> > > > > > > >
> > > > > > > > One more update: I just spoke with Xiaoxiang and we've
> reached
> > > some
> > > > > > > common
> > > > > > > > ground. He's no longer opposed to the current stack
> > > implementation
> > > > > and
> > > > > > > > agrees that the focus should be on proper structuring. Here's
> > the
> > > > > plan
> > > > > > > > going forward:
> > > > > > > >
> > > > > > > > 1. Unused shell code will be moved out of the stack and
> into
> > > > > apps/,
> > > > > > > > running entirely in userspace.
> > > > > > > > 2. Bluetooth profiles will be migrated to libs/libbt/,
> where
> > > > we'll
> > > > > > > > provide two OS API backends: a POSIX API implementation
> (for
> > > > > > > > kernel/protected builds) and a NuttX kernel API
> > implementation
> > > > > (for
> > > > > > > flat
> > > > > > > > mode).
> > > > > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > > > > >
> > > > > > > > This should address the architectural concerns while
> preserving
> > > the
> > > > > > > > performance path for flat-mode deployments.
> > > > > > > >
> > > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > > > > > >
> > > > > > > > > Hi An Chao,
> > > > > > > > >
> > > > > > > > > Thank you for trying to improve the NuttX Bluetooth
> support.
> > > And
> > > > > > thank
> > > > > > > > you
> > > > > > > > > to bring this discussion here to let more people give their
> > > > > opinion.
> > > > > > > > >
> > > > > > > > > I think most of the concerns raised by Xiang and Raiden
> > > (Mateusz)
> > > > > are
> > > > > > > > > important and need to be addressed.
> > > > > > > > >
> > > > > > > > > As I said at GitHub PR I think a main concern here is using
> > the
> > > > > same
> > > > > > > > > Bluetooth stack used on Zephyr, not because it is a bad
> stack
> > > (of
> > > > > > > course
> > > > > > > > it
> > > > > > > > > is not, it was developed by experts on Bluetooth area), but
> > > > because
> > > > > > we
> > > > > > > > are
> > > > > > > > > adding the same surface area of attack from Zephyr on
> NuttX.
> > > > > > > > >
> > > > > > > > > That means any security vulnerability affecting Zephyr BLE
> > > stack
> > > > > will
> > > > > > > > > affect NuttX. It remove the protection that a companies
> could
> > > > > obtain
> > > > > > > when
> > > > > > > > > using different RTOSs.
> > > > > > > > >
> > > > > > > > > Also, if my memory still serving me, I think Xiaomi team
> (you
> > > was
> > > > > > there
> > > > > > > > at
> > > > > > > > > that time) already tried to submit their initial port of
> > Zephyr
> > > > BLE
> > > > > > > stack
> > > > > > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > > > > > >
> > > > > > > > > His suggestion was to improve our BLE stack, that in fact
> has
> > > the
> > > > > > same
> > > > > > > > > origin of the Zephyr BLE stack (both came from a BLE stack
> > from
> > > > > Intel
> > > > > > > > > released as BSD license at that time).
> > > > > > > > >
> > > > > > > > > I'm not against including the Zephyr BLE stack, but it
> should
> > > be
> > > > > > > > > selectable. Ideally the user should select if he/she wants
> to
> > > use
> > > > > > > NimBLE,
> > > > > > > > > Zephyr or NuttX native BLE stack.
> > > > > > > > >
> > > > > > > > > BR,
> > > > > > > > >
> > > > > > > > > Alan
> > > > > > > > >
> > > > > > > > > On Friday, October 16, 2026, chao an <ma...@gmail.com>
> > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi, Tomek,
> > > > > > > > > >
> > > > > > > > > > Thanks for the thoughtful input and the FreeBSD
> references
> > —
> > > > > those
> > > > > > > are
> > > > > > > > > very
> > > > > > > > > > relevant to where we're heading.
> > > > > > > > > >
> > > > > > > > > > Just to set the context: NuttX's current Bluetooth stack
> > only
> > > > > > > supports
> > > > > > > > > BLE.
> > > > > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all
> > > > > missing.
> > > > > > > This
> > > > > > > > > is
> > > > > > > > > > exactly why we want to bring a more complete Bluetooth
> > stack
> > > to
> > > > > > > NuttX —
> > > > > > > > > to
> > > > > > > > > > catch up with what mainstream RTOS communities already
> > offer.
> > > > > > > > > >
> > > > > > > > > > I actually agree with the FreeBSD/Apple architecture you
> > > > > > referenced.
> > > > > > > > Our
> > > > > > > > > > end-state plan is similar: the L2CAP and HCI layers will
> > live
> > > > in
> > > > > > the
> > > > > > > > > > kernel, and a bluetoothd-style daemon will be implemented
> > in
> > > > > libc,
> > > > > > > > > managing
> > > > > > > > > > profiles and higher-level protocols. This gives us a
> clean
> > > > > > > separation —
> > > > > > > > > > transport in the kernel, policy and profiles in
> userspace —
> > > > much
> > > > > > like
> > > > > > > > how
> > > > > > > > > > FreeBSD's ng_hci / hccontrol split works. The current PR
> is
> > > > > Phase 1
> > > > > > > of
> > > > > > > > > > getting there incrementally.
> > > > > > > > > >
> > > > > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > > > > > >
> > > > > > > > > > > Thank you An Chao for this proposition, work, and
> > > discussion
> > > > > :-)
> > > > > > > > > > >
> > > > > > > > > > > For sure it would be nice to have a BT stack with more
> > > > > features!
> > > > > > > The
> > > > > > > > > > > BT has known issue of having different implementations
> of
> > > the
> > > > > > stack
> > > > > > > > on
> > > > > > > > > > > different RTOS / OS / platforms, which is a known
> issue,
> > > and
> > > > > > kinda
> > > > > > > > > > > mess because there is no common standard / approach /
> > > > > > > implementation,
> > > > > > > > > > > unfortunately around something that is supposed to be
> > based
> > > > on
> > > > > a
> > > > > > > > > > > common standard.
> > > > > > > > > > >
> > > > > > > > > > > Having common BT stack with other popular RTOS may make
> > > > > > portability
> > > > > > > > > > > easier and developers move to NuttX in some cases.
> > > > > > > > > > >
> > > > > > > > > > > I understand that we are talking about this solution?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > > > > connectivity/bluetooth/index.html
> > > > > > > > > > >
> > > > > > > > > > > In a perfect situation we would want to have modular
> > > > > > implementation
> > > > > > > > in
> > > > > > > > > > > nuttx-apps just like nimble. This is pointed out by
> > Xiang,
> > > > > > Raiden,
> > > > > > > > and
> > > > > > > > > > > Alin already. But I understand some things may be hard
> to
> > > > > > implement
> > > > > > > > > > > that way. I will follow the consensus here when ready,
> I
> > > have
> > > > > no
> > > > > > > > > > > strong opinion here, except any BT stack I touched
> before
> > > > was a
> > > > > > > mess
> > > > > > > > > > > and I hope we can work out at least something decent
> :-P
> > > > > > > > > > >
> > > > > > > > > > > A bit offtopic but for kernel build we can take a look
> at
> > > > quite
> > > > > > old
> > > > > > > > > > > Bluetooth implementation on FreeBSD, where radio is
> > > provided
> > > > by
> > > > > > > > ng_ubt
> > > > > > > > > > > (lower half in out case), then upper half uses standard
> > > HCI.
> > > > > > Maybe
> > > > > > > > > > > something like this is possible in NuttX?
> > > > > > > > > > >
> > > > > > > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > > > > 4.
> > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > > > > 5.
> > > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > > > > >
> > > > > > > > > > > Here is a quick overview article on the Bluetooth
> > > > > implementation
> > > > > > in
> > > > > > > > > > > FreeBSD and Apple:
> > > > > > > > > > >
> > > > > > > > > > >
> > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > > > > >
> > > > > > > > > > > Again it will be very nice to have fully featured BT
> > stack
> > > in
> > > > > > NuttX
> > > > > > > > > > > and I hope we can sort out the best possible porting
> > > > > > implementation
> > > > > > > > > > > :-)
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > > > > jerpelea@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > thanks Xiao and Raiden for your technical opinions
> > which
> > > I
> > > > > also
> > > > > > > > share
> > > > > > > > > > so
> > > > > > > > > > > I
> > > > > > > > > > > > will not iterate them again.
> > > > > > > > > > > >
> > > > > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > > > > it should be splitted between nuttx and apps-repos
> and
> > > use
> > > > > > POSIX
> > > > > > > > > > > > implementation as much as possible. We are focused on
> > > > > standards
> > > > > > > and
> > > > > > > > > > > > compatibility.
> > > > > > > > > > > >
> > > > > > > > > > > > Another concern is the license which does not match
> our
> > > ASF
> > > > > one
> > > > > > > and
> > > > > > > > > > does
> > > > > > > > > > > > not include any LICENSE file additions to clarify the
> > > > > compiance
> > > > > > > > > aspect
> > > > > > > > > > > >
> > > > > > > > > > > > Best regards
> > > > > > > > > > > > Alin J
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > > > > xiaoxiang781216@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > > > > magicdcps@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > So the real reason you've been objecting to my
> > > proposal
> > > > > is
> > > > > > > that
> > > > > > > > > > your
> > > > > > > > > > > team
> > > > > > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If you can give me a clear timeline for when your
> > > > > > > > implementation
> > > > > > > > > > > will be
> > > > > > > > > > > > > > submitted upstream, I'm happy to withdraw my PR
> and
> > > let
> > > > > > your
> > > > > > > > code
> > > > > > > > > > > serve
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > the baseline. I'm not here to fight over
> ownership
> > of
> > > > the
> > > > > > > > > Bluetooth
> > > > > > > > > > > > > stack.
> > > > > > > > > > > > > > My only motivation is that NuttX's lack of a
> > capable
> > > > > > > Bluetooth
> > > > > > > > > > stack
> > > > > > > > > > > is
> > > > > > > > > > > > > > driving every developer toward Zephyr — and as a
> > PMC
> > > > > > member,
> > > > > > > I
> > > > > > > > > > think
> > > > > > > > > > > you
> > > > > > > > > > > > > > should be asking yourselves why this gap has
> > remained
> > > > > > > unfilled
> > > > > > > > > for
> > > > > > > > > > so
> > > > > > > > > > > > > long.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > I object to landing the whole bluetooth stack into
> > > kernel
> > > > > > space
> > > > > > > > > > > directly
> > > > > > > > > > > > > either yours and ours .
> > > > > > > > > > > > > This is the same feeling from raiden00pl too, let's
> > see
> > > > > other
> > > > > > > > > > people's
> > > > > > > > > > > > > opinions here.
> > > > > > > > > > > > > But it's fine for me to host the whole code in
> > > > > nuttx-apps.git
> > > > > > > and
> > > > > > > > > > > refactor
> > > > > > > > > > > > > components to kernel
> > > > > > > > > > > > > space step by step.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > As for the current PR, I'll remove the shell
> > > components
> > > > > > from
> > > > > > > > the
> > > > > > > > > > > stack
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > move them into apps/ where they belong. The base
> > > > profiles
> > > > > > > > (A2DP,
> > > > > > > > > > BLE)
> > > > > > > > > > > > > will
> > > > > > > > > > > > > > stay in libc —
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The architecture is wrong to host any bluetooth
> > > profile
> > > > in
> > > > > > > libc.
> > > > > > > > > > > > >
> > > > > > > > > > > > > in flat build mode this gives a significant
> > performance
> > > > > > > > > > > > > > boost to the overall stack, which is the primary
> > > > > deployment
> > > > > > > > model
> > > > > > > > > > for
> > > > > > > > > > > > > most
> > > > > > > > > > > > > > NuttX devices.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > Performance should remain the same whether the base
> > > > profile
> > > > > > is
> > > > > > > > > hosted
> > > > > > > > > > > in
> > > > > > > > > > > > > libc or apps,
> > > > > > > > > > > > > could you point out any technical reason which
> > impacts
> > > > the
> > > > > > > > > > performance
> > > > > > > > > > > in
> > > > > > > > > > > > > the flat mode?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > A few additional data points regarding our
> > timeline:
> > > > our
> > > > > > > > product
> > > > > > > > > is
> > > > > > > > > > > > > > scheduled for release in December, and Bluetooth
> > SIG
> > > > > > > > > certification
> > > > > > > > > > is
> > > > > > > > > > > > > > already in progress — we expect to receive it
> > around
> > > > > > > November.
> > > > > > > > If
> > > > > > > > > > the
> > > > > > > > > > > > > > baseline were to switch to your team's stack with
> > its
> > > > > > > different
> > > > > > > > > > > > > > architecture, that certification cycle would need
> > to
> > > be
> > > > > > > > repeated,
> > > > > > > > > > > which
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Xiang Xiao <xi...@gmail.com>
> > > 于2026年10月16日周五
> > > > > > > 15:08写道：
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > > > > magicdcps@gmail.com
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Regarding your point about the NimBLE port
> > using
> > > > the
> > > > > > > POSIX
> > > > > > > > > API
> > > > > > > > > > —
> > > > > > > > > > > yes,
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > uses POSIX, but there are real issues with
> the
> > > > > current
> > > > > > > > > > > implementation
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real
> > > critical
> > > > > > > section
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This is a mutex, not a critical section. It
> > does
> > > > not
> > > > > > > > disable
> > > > > > > > > > > > > interrupts
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > preemption — an ISR can still fire and
> corrupt
> > > data
> > > > > > that
> > > > > > > > the
> > > > > > > > > > > > > "critical
> > > > > > > > > > > > > > > > section" was supposed to protect. On top of
> > that,
> > > > > > using a
> > > > > > > > > mutex
> > > > > > > > > > > opens
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > door to ABBA deadlocks when combined with any
> > > other
> > > > > > lock
> > > > > > > > held
> > > > > > > > > > > inside
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > critical region:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - Thread A: enter_critical →
> lock(s_mutex) →
> > > try
> > > > > > > > > lock(mutex
> > > > > > > > > > > M) ←
> > > > > > > > > > > > > > > blocked
> > > > > > > > > > > > > > > > by B
> > > > > > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > > > > > lock(s_mutex) ←
> > > > > > > > > > > blocked by
> > > > > > > > > > > > > A
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Compare this with the FreeRTOS port, which
> > > > correctly
> > > > > > uses
> > > > > > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical()
> > (i.e.,
> > > > > > > actually
> > > > > > > > > > > disabling
> > > > > > > > > > > > > > > > scheduling/preemption). The current NuttX
> port
> > > > simply
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > > > meet
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > semantic contract that the NimBLE stack
> expects
> > > > from
> > > > > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > > > > 2. Time subsystem uses clock_gettime instead
> of
> > > > > kernel
> > > > > > > tick
> > > > > > > > > > APIs
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > > > > ...),
> > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > involves a syscall and floating-point
> > arithmetic
> > > on
> > > > > > every
> > > > > > > > > call.
> > > > > > > > > > > In a
> > > > > > > > > > > > > > BLE
> > > > > > > > > > > > > > > > stack where timestamps and timing are on the
> > hot
> > > > > path,
> > > > > > > this
> > > > > > > > > > adds
> > > > > > > > > > > > > > > measurable
> > > > > > > > > > > > > > > > overhead compared to accessing the kernel
> tick
> > > > > counter
> > > > > > > > > > directly.
> > > > > > > > > > > > > > > > 3. Others are already using the kernel
> > approach —
> > > > and
> > > > > > for
> > > > > > > > > good
> > > > > > > > > > > reason
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack
> > > > (zblue)
> > > > > > for
> > > > > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX
> for
> > > the
> > > > > > > > > > > > > performance-critical
> > > > > > > > > > > > > > > > paths:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This isn't an academic exercise — it's a
> > > production
> > > > > > > choice.
> > > > > > > > > > They
> > > > > > > > > > > > > > > recognized
> > > > > > > > > > > > > > > > that a BLE stack needs tight integration with
> > the
> > > > OS
> > > > > > > timer
> > > > > > > > > > > subsystem,
> > > > > > > > > > > > > > > > direct access to critical section primitives,
> > and
> > > > > > > efficient
> > > > > > > > > > event
> > > > > > > > > > > > > > > delivery,
> > > > > > > > > > > > > > > > none of which POSIX provides well in this
> > > context.
> > > > > > > > > > > > > > > > My question
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If other organizations are already using a
> more
> > > > > > > performant,
> > > > > > > > > > > > > > > architecturally
> > > > > > > > > > > > > > > > correct kernel-level integration for their
> BLE
> > > > stacks
> > > > > > on
> > > > > > > > > NuttX,
> > > > > > > > > > > why
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > we be told that we must use the slower, less
> > > > correct
> > > > > > > POSIX
> > > > > > > > > > path?
> > > > > > > > > > > > > > NuttX's
> > > > > > > > > > > > > > > > POSIX compliance is valuable, but it
> shouldn't
> > > come
> > > > > at
> > > > > > > the
> > > > > > > > > cost
> > > > > > > > > > > of
> > > > > > > > > > > > > > > shipping
> > > > > > > > > > > > > > > > a BLE stack with a broken critical section
> > > > primitive.
> > > > > > > There
> > > > > > > > > > > should be
> > > > > > > > > > > > > > > room
> > > > > > > > > > > > > > > > for both approaches, and the decision should
> be
> > > > > driven
> > > > > > by
> > > > > > > > > > > technical
> > > > > > > > > > > > > > > merit,
> > > > > > > > > > > > > > > > not by treating POSIX as the only acceptable
> > > > answer.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't object to moving the key bluetooth
> stack
> > to
> > > > > > kernel
> > > > > > > > > space
> > > > > > > > > > > like
> > > > > > > > > > > > > how
> > > > > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is
> > far
> > > to
> > > > > > move
> > > > > > > > > > entirely
> > > > > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > > > > If I low my quality bar, I have requested my
> > > teammate
> > > > > to
> > > > > > > > > upstream
> > > > > > > > > > > our
> > > > > > > > > > > > > > > implementation:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > > since much work needs to be done before it can
> > > > achieve
> > > > > > the
> > > > > > > > > > quality
> > > > > > > > > > > > > > > upstream.
> > > > > > > > > > > > > > > BTW, many zephyr class BT features are
> developed
> > by
> > > > my
> > > > > > team
> > > > > > > > and
> > > > > > > > > > > > > upstream
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > > > > If considering the quality, our version is much
> > > > better
> > > > > > > since:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2
> certification
> > > at
> > > > > > > 2026.06
> > > > > > > > > > > > > > > 3. Product on wear device by end of this
> year
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Anchao,
Sounds good!
Yes, I suggest going with more explicitly selection in the Kconfig so users
can select what they want more easily.
Regarding "net/bt," there is not a more permanent solution than a temporary
one. This is a reason to avoid it.
I understand that you tested the integration this way and agreed to change
it to libs/zblue later, but I strongly recommend making that change before
merging.
Adding something that will probably change will result in a "breaking
change" later, which we are trying to avoid on NuttX.
So the best moment to change it is before it gets merged. If you need help
testing, I can assist here. I'm already working on BT (first fixing small
issues).
BR,
Alan
On Thu, Oct 22, 2026 at 8:55 AM chao an <ma...@gmail.com> wrote:
> Hi Alan,
>
> Yes, I agree that we need to find a middle ground and make sure the
> integration does not block the existing Bluetooth solutions in NuttX.
>
> From the current implementation, I don't think this zblue-based stack
> conflicts with NimBLE or with the existing in-tree BLE stack. They can be
> selected independently through Kconfig. For example:
>
> - CONFIG_BT Enables the new zblue-based host stack currently added by
> this PR.
> - CONFIG_WIRELESS_BLUETOOTH
> - CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE stack
> under wireless/bluetooth.
> - CONFIG_NIMBLE Enables the userspace NimBLE stack when that stack is
> used from apps.
>
> The lower-level Bluetooth controller / transport drivers are also separate,
> for example:
>
> - CONFIG_BLUETOOTH_UART
> - CONFIG_BLUETOOTH_RPMSG
> - CONFIG_BLUETOOTH_NULL
>
> So I think it is possible to make the three options coexist on NuttX, as
> long as we keep the host-stack selection separated and avoid enabling two
> host stacks for the same controller path at the same time. If needed, we
> can also make this more explicit by adding a Kconfig choice or mutual
> exclusion between the host stacks.
>
> Regarding the location, I understand your point about libs/zblue. However,
> for the initial version, I still think keeping the full stack under net/bt
> is the safer integration path.
>
> The reason is that splitting it into libs/zblue is not only a directory
> rename. To do that correctly, we need to isolate each profile and data path
> according to its own characteristics. Some profiles are not just pure
> userspace library logic. For example, SCO and LE Audio / ISO have
> lower-level data paths. On Linux, part of this kind of traffic is handled
> or forwarded by the kernel side. So if we move everything to libs/zblue too
> early, we may create an artificial boundary that is not correct for those
> lower-level profiles.
>
> My suggestion is:
>
> 1. Keep the initial version integrated under net/bt, so the controller,
> HCI, L2CAP, ISO/SCO and profile paths can work correctly first.
> 2. Make the stack name clear as zblue if the community prefers that, so
> it is not presented as replacing the existing NuttX BLE stack.
> 3. Keep the Kconfig separation so users can choose between:
> - zblue-based stack,
> - existing NuttX BLE stack,
> - NimBLE userspace stack.
> 4. After the initial integration is stable, we can evaluate moving or
> splitting parts into libs/zblue profile by profile, where the boundary
> is
> technically clear.
>
> So yes, I think it is possible to modify the PR to let both stacks plus
> NimBLE work on NuttX without interfering with each other. I just think
> doing a full libs/zblue separation as the first step may be risky,
> especially for the lower-level profiles and audio-related paths.
>
> Does this direction sound acceptable to you?
>
> BR,
>
> Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 19:32写道：
>
> > Hi Anchao,
> >
> > Yes, I think having a complete BLE stack like zblue is a good idea.
> >
> > But we need to find a middle ground for correct integration.
> >
> > Let's do this: add zblue to libs/zglue and maintain a proper separation
> to
> > allow room for the existing BLE stack on NuttX to evolve.
> >
> > Just assuming that not updating/synchroning zblue with Zephyr's zblue
> will
> > be enough for them to become different entities seems incorrect.
> >
> > The amount of code is very large, so even after decades they will share
> > enough of their "DNA" that a virus will be able to infect both.
> >
> > Do you think it is possible to modify your PR to let both stacks (+
> NimBLE
> > userspace stack) work on NuttX without one interfering on the other?
> >
> > BR,
> >
> > Alan
> >
> > On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi Alan,
> > >
> > >
> > >
> > > Thank you for the detailed analysis.
> > >
> > >
> > >
> > > I understand your concern. The current code structure is indeed still
> > very
> > >
> > > close to Zephyr's Bluetooth stack, and the compatibility layer is
> > currently
> > >
> > > quite thin. However, from the long-term technical direction, our
> > intention
> > > is
> > > not to keep doing long-term synchronization with Zephyr. Instead, we
> plan
> > > to
> > > quickly feed back the related issues and improvements to the NuttX
> > > community
> > > during the integration and evolution process.
> > >
> > >
> > >
> > > Regarding the naming concern, I think it is reasonable to call it zblue
> > >
> > > temporarily, since the current implementation is still largely based on
> > >
> > > Zephyr's Bluetooth stack. If the stack evolves later with a new code
> > > structure
> > > and clearer NuttX-specific architecture, we can further evaluate
> whether
> > a
> > >
> > > different name would be more appropriate at that time.
> > >
> > >
> > >
> > > Does that sound reasonable to you?
> > >
> > >
> > >
> > > BR,
> > >
> > >
> > > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> > >
> > > > Hi Anchao,
> > > >
> > > > I used Claude to help compare the code and here are the reasons to
> call
> > > it
> > > > zblue instead of libs/bt:
> > > >
> > > > Almost all of this PR is Zephyr's Bluetooth stack
> > > > ("zblue"), reformatted to NuttX style. The part that doesn't come
> from
> > > > Zephyr is
> > > > a thin compatibility layer that makes the Zephyr kernel calls work on
> > > > NuttX.
> > > >
> > > > I pulled all 539 new files (400,450 lines) and compared them against
> > > > several
> > > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it
> matches
> > > > better
> > > > than Zephyr's current main branch. So the PR looks like a snapshot of
> > > zblue
> > > > from the last few weeks.
> > > >
> > > > Results
> > > >
> > > > Function by function (7,716 functions):
> > > >
> > > > Class: Identical
> > > > Functions: 5,411 (70%)
> > > > Lines: 140,189
> > > > Meaning: Exactly the same code as Zephyr. Only indentation and
> braces
> > > > differ.
> > > > ────────────────────────────────────────
> > > > Class: Renames only
> > > > Functions: 1,515 (20%)
> > > > Lines: 60,863
> > > > Meaning: The only changes are API renames that recur across the
> whole
> > > PR:
> > > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> > > sys_slist_*→list_*,
> > > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read
> > > > ────────────────────────────────────────
> > > > Class: Modified
> > > > Functions: 584 (8%)
> > > > Lines: 33,693
> > > > Meaning: Clearly the Zephyr function, plus some edits specific to
> > that
> > > > function
> > > > ────────────────────────────────────────
> > > > Class: Not from Zephyr
> > > > Functions: 206 (3%)
> > > > Lines: 2,734
> > > > Meaning: NuttX glue code
> > > >
> > > > Whole files, including headers:
> > > > - On average, 96.9% of each file's code also appears in its Zephyr
> > > > counterpart.
> > > > - 434 of the 539 files are ≥90% the same as Zephyr; together they
> > hold
> > > > 375k of
> > > > the 400k lines.
> > > > - 75% of the comment text, including the Doxygen docs, is
> > word-for-word
> > > > Zephyr.
> > > >
> > > > What's actually new:
> > > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c,
> > mem_slab.c,
> > > > fs.c,
> > > > sections/defines.c, hci_driver.c), which provides k_work, k_queue
> > and
> > > > similar
> > > > Zephyr calls on top of NuttX.
> > > > - Part of mm/net_buf.
> > > > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig.
> > > >
> > > >
> > > > So, only 3% of the code is new (this includes the code in sim:bt that
> > > must
> > > > be new).
> > > >
> > > > So, reusing the zblue from Zephyr and calling it something else isn't
> > > > right; it's like the zbus that Jorge brought from Zephyr, where
> calling
> > > it
> > > > NXBus doesn't seem appropriate.
> > > >
> > > > Besides that, as I said before using ZBlue as our official BT Stack
> > will
> > > > significantly increase the shared code between NuttX and Zephyr,
> which
> > > > could be dangerous.
> > > >
> > > > As I said, I not against adding ZBlue to NuttX, but at least make it
> > > clear
> > > > that it is ZBlue and should be an alternative stack (like NimBLE) not
> > the
> > > > official NuttX BLE Stack.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com>
> wrote:
> > > >
> > > > > Hi Alan,
> > > > >
> > > > > Thanks for the comments and suggestions.
> > > > >
> > > > > For the first stage, I would prefer to keep the Bluetooth host
> stack
> > > > > supported only in FLAT mode. Supporting Protected and Kernel modes
> > > > requires
> > > > > a much deeper rework of the stack and its interfaces, especially
> > around
> > > > the
> > > > > boundary between kernel space and user space. I do not think it is
> a
> > > good
> > > > > idea to introduce such large architectural changes in this first
> > step.
> > > > >
> > > > > Our current plan is to complete Protected/Kernel mode support in a
> > > second
> > > > > stage, after the basic stack integration is reviewed and
> stabilized.
> > > This
> > > > > should make the initial review and integration much more
> manageable.
> > > > >
> > > > > Regarding the library name, I still prefer to use libs/libbt.
> > Although
> > > > the
> > > > > current code is based on Zephyr's zblue, the goal is to maintain it
> > as
> > > an
> > > > > independent NuttX Bluetooth host stack going forward, rather than
> > > keeping
> > > > > it as a direct Zephyr fork forever. In that sense, I think libbt
> is a
> > > > > better long-term name.
> > > > >
> > > > > Also, the current NuttX Bluetooth profiles are not implemented in
> the
> > > > > kernel, and we do not plan to move the native NuttX Bluetooth stack
> > > > > profiles into the kernel either. Once Protected/Kernel mode support
> > is
> > > > > added for this stack in the future, this implementation is expected
> > to
> > > > > replace the previous approach. For this reason, I think keeping the
> > > stack
> > > > > under libbt is still more appropriate.
> > > > >
> > > > > About splitting the PR: this PR is already the result of squashing
> > more
> > > > > than one hundred commits. Most of those commits are
> > compatibility-layer
> > > > > adjustments, coding style cleanup, and mechanical changes needed to
> > > make
> > > > > the stack build in NuttX. Asking reviewers to review each of those
> > > > commits
> > > > > separately would probably cost everyone more time.
> > > > >
> > > > > Splitting the full Bluetooth stack by profile is also not very
> > > practical
> > > > at
> > > > > the moment, because there are no dedicated maintainers for each
> > > > individual
> > > > > Bluetooth profile area in NuttX yet. Therefore, I think the current
> > > form
> > > > is
> > > > > probably the most reasonable way to review and integrate the stack
> > as a
> > > > > whole.
> > > > >
> > > > > One more update: I have removed all shell-related code from
> > > > > https://github.com/apache/nuttx/pull/20686. The plan is to move
> > those
> > > > > shell
> > > > > commands to apps later. With this change, the current Bluetooth
> stack
> > > no
> > > > > longer contains any user-space shell code, so I think this is now a
> > > > better
> > > > > point for review.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > > > >
> > > > > > Hi An Chao,
> > > > > >
> > > > > > Isn't it possible to have a similar implementation that works for
> > > FLAT,
> > > > > > Protected and Kernel modes?
> > > > > >
> > > > > > This way the maintenance will be easier. Only small
> kernel-specific
> > > > parts
> > > > > > will remain there (as Raiden and Xiang proposed).
> > > > > >
> > > > > > Suggestion: instead of naming it libs/libbt/, it would be better
> to
> > > use
> > > > > > libs/zblue to make it clear that it is a zblue port from Zephyr.
> > > > > >
> > > > > > Let's use libs/libbt only for NuttX-specific (native) code.
> > > > > >
> > > > > > And as I said, it is better to easily isolate the code that came
> > from
> > > > > > Zephyr's zblue.
> > > > > >
> > > > > > This way the user could select the Bluetooth stack they want
> > without
> > > > > having
> > > > > > code from the other stack attached to it.
> > > > > >
> > > > > > Also I suggest you to break your PR into smaller PRs; a single PR
> > > > > changing
> > > > > > more than 660K LoC is very massive.
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com>
> > wrote:
> > > > > >
> > > > > > > Hi Alan,
> > > > > > >
> > > > > > > Thank you for the thoughtful perspective and for engaging in
> the
> > > > > > > discussion.
> > > > > > >
> > > > > > > On security: we will maintain the Bluetooth stack ourselves and
> > > take
> > > > > > > responsibility for tracking and fixing vulnerabilities. I'm
> also
> > > > > > confident
> > > > > > > that Xiaomi will contribute back on security issues given their
> > > > ongoing
> > > > > > > investment in this codebase. This isn't a blind import — it's
> > code
> > > > that
> > > > > > has
> > > > > > > active, committed maintainers behind it.
> > > > > > >
> > > > > > > Regarding the history with Greg: you're right that we discussed
> > > this
> > > > > > years
> > > > > > > ago. But there's an important distinction — that earlier
> proposal
> > > > > placed
> > > > > > > the stack entirely in userspace. It did nothing to strengthen
> > > NuttX's
> > > > > > > kernel-level Bluetooth support. That's precisely why I'm back
> > now,
> > > > > > > providing a kernel implementation this time around, which is
> > what I
> > > > > > > committed to back then. Feel free to search the mailing list
> > > > archives —
> > > > > > the
> > > > > > > NuttX native Bluetooth stack will evolve from this baseline
> going
> > > > > > forward.
> > > > > > >
> > > > > > > This implementation does not affect existing Bluetooth stacks
> in
> > > any
> > > > > way.
> > > > > > > Users can still choose NimBLE, the current NuttX BLE stack, or
> > any
> > > > > other
> > > > > > > solution. This is an additional option, not a replacement. The
> > goal
> > > > is
> > > > > to
> > > > > > > give NuttX users more choices, not fewer.
> > > > > > >
> > > > > > > One more update: I just spoke with Xiaoxiang and we've reached
> > some
> > > > > > common
> > > > > > > ground. He's no longer opposed to the current stack
> > implementation
> > > > and
> > > > > > > agrees that the focus should be on proper structuring. Here's
> the
> > > > plan
> > > > > > > going forward:
> > > > > > >
> > > > > > > 1. Unused shell code will be moved out of the stack and into
> > > > apps/,
> > > > > > > running entirely in userspace.
> > > > > > > 2. Bluetooth profiles will be migrated to libs/libbt/, where
> > > we'll
> > > > > > > provide two OS API backends: a POSIX API implementation (for
> > > > > > > kernel/protected builds) and a NuttX kernel API
> implementation
> > > > (for
> > > > > > flat
> > > > > > > mode).
> > > > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > > > >
> > > > > > > This should address the architectural concerns while preserving
> > the
> > > > > > > performance path for flat-mode deployments.
> > > > > > >
> > > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > > > > >
> > > > > > > > Hi An Chao,
> > > > > > > >
> > > > > > > > Thank you for trying to improve the NuttX Bluetooth support.
> > And
> > > > > thank
> > > > > > > you
> > > > > > > > to bring this discussion here to let more people give their
> > > > opinion.
> > > > > > > >
> > > > > > > > I think most of the concerns raised by Xiang and Raiden
> > (Mateusz)
> > > > are
> > > > > > > > important and need to be addressed.
> > > > > > > >
> > > > > > > > As I said at GitHub PR I think a main concern here is using
> the
> > > > same
> > > > > > > > Bluetooth stack used on Zephyr, not because it is a bad stack
> > (of
> > > > > > course
> > > > > > > it
> > > > > > > > is not, it was developed by experts on Bluetooth area), but
> > > because
> > > > > we
> > > > > > > are
> > > > > > > > adding the same surface area of attack from Zephyr on NuttX.
> > > > > > > >
> > > > > > > > That means any security vulnerability affecting Zephyr BLE
> > stack
> > > > will
> > > > > > > > affect NuttX. It remove the protection that a companies could
> > > > obtain
> > > > > > when
> > > > > > > > using different RTOSs.
> > > > > > > >
> > > > > > > > Also, if my memory still serving me, I think Xiaomi team (you
> > was
> > > > > there
> > > > > > > at
> > > > > > > > that time) already tried to submit their initial port of
> Zephyr
> > > BLE
> > > > > > stack
> > > > > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > > > > >
> > > > > > > > His suggestion was to improve our BLE stack, that in fact has
> > the
> > > > > same
> > > > > > > > origin of the Zephyr BLE stack (both came from a BLE stack
> from
> > > > Intel
> > > > > > > > released as BSD license at that time).
> > > > > > > >
> > > > > > > > I'm not against including the Zephyr BLE stack, but it should
> > be
> > > > > > > > selectable. Ideally the user should select if he/she wants to
> > use
> > > > > > NimBLE,
> > > > > > > > Zephyr or NuttX native BLE stack.
> > > > > > > >
> > > > > > > > BR,
> > > > > > > >
> > > > > > > > Alan
> > > > > > > >
> > > > > > > > On Friday, October 16, 2026, chao an <ma...@gmail.com>
> > > wrote:
> > > > > > > >
> > > > > > > > > Hi, Tomek,
> > > > > > > > >
> > > > > > > > > Thanks for the thoughtful input and the FreeBSD references
> —
> > > > those
> > > > > > are
> > > > > > > > very
> > > > > > > > > relevant to where we're heading.
> > > > > > > > >
> > > > > > > > > Just to set the context: NuttX's current Bluetooth stack
> only
> > > > > > supports
> > > > > > > > BLE.
> > > > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all
> > > > missing.
> > > > > > This
> > > > > > > > is
> > > > > > > > > exactly why we want to bring a more complete Bluetooth
> stack
> > to
> > > > > > NuttX —
> > > > > > > > to
> > > > > > > > > catch up with what mainstream RTOS communities already
> offer.
> > > > > > > > >
> > > > > > > > > I actually agree with the FreeBSD/Apple architecture you
> > > > > referenced.
> > > > > > > Our
> > > > > > > > > end-state plan is similar: the L2CAP and HCI layers will
> live
> > > in
> > > > > the
> > > > > > > > > kernel, and a bluetoothd-style daemon will be implemented
> in
> > > > libc,
> > > > > > > > managing
> > > > > > > > > profiles and higher-level protocols. This gives us a clean
> > > > > > separation —
> > > > > > > > > transport in the kernel, policy and profiles in userspace —
> > > much
> > > > > like
> > > > > > > how
> > > > > > > > > FreeBSD's ng_hci / hccontrol split works. The current PR is
> > > > Phase 1
> > > > > > of
> > > > > > > > > getting there incrementally.
> > > > > > > > >
> > > > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > > > > >
> > > > > > > > > > Thank you An Chao for this proposition, work, and
> > discussion
> > > > :-)
> > > > > > > > > >
> > > > > > > > > > For sure it would be nice to have a BT stack with more
> > > > features!
> > > > > > The
> > > > > > > > > > BT has known issue of having different implementations of
> > the
> > > > > stack
> > > > > > > on
> > > > > > > > > > different RTOS / OS / platforms, which is a known issue,
> > and
> > > > > kinda
> > > > > > > > > > mess because there is no common standard / approach /
> > > > > > implementation,
> > > > > > > > > > unfortunately around something that is supposed to be
> based
> > > on
> > > > a
> > > > > > > > > > common standard.
> > > > > > > > > >
> > > > > > > > > > Having common BT stack with other popular RTOS may make
> > > > > portability
> > > > > > > > > > easier and developers move to NuttX in some cases.
> > > > > > > > > >
> > > > > > > > > > I understand that we are talking about this solution?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > > > connectivity/bluetooth/index.html
> > > > > > > > > >
> > > > > > > > > > In a perfect situation we would want to have modular
> > > > > implementation
> > > > > > > in
> > > > > > > > > > nuttx-apps just like nimble. This is pointed out by
> Xiang,
> > > > > Raiden,
> > > > > > > and
> > > > > > > > > > Alin already. But I understand some things may be hard to
> > > > > implement
> > > > > > > > > > that way. I will follow the consensus here when ready, I
> > have
> > > > no
> > > > > > > > > > strong opinion here, except any BT stack I touched before
> > > was a
> > > > > > mess
> > > > > > > > > > and I hope we can work out at least something decent :-P
> > > > > > > > > >
> > > > > > > > > > A bit offtopic but for kernel build we can take a look at
> > > quite
> > > > > old
> > > > > > > > > > Bluetooth implementation on FreeBSD, where radio is
> > provided
> > > by
> > > > > > > ng_ubt
> > > > > > > > > > (lower half in out case), then upper half uses standard
> > HCI.
> > > > > Maybe
> > > > > > > > > > something like this is possible in NuttX?
> > > > > > > > > >
> > > > > > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > > > 4.
> > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > > > 5.
> > > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > > > >
> > > > > > > > > > Here is a quick overview article on the Bluetooth
> > > > implementation
> > > > > in
> > > > > > > > > > FreeBSD and Apple:
> > > > > > > > > >
> > > > > > > > > >
> > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > > > >
> > > > > > > > > > Again it will be very nice to have fully featured BT
> stack
> > in
> > > > > NuttX
> > > > > > > > > > and I hope we can sort out the best possible porting
> > > > > implementation
> > > > > > > > > > :-)
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > > > >
> > > > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > > > jerpelea@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > thanks Xiao and Raiden for your technical opinions
> which
> > I
> > > > also
> > > > > > > share
> > > > > > > > > so
> > > > > > > > > > I
> > > > > > > > > > > will not iterate them again.
> > > > > > > > > > >
> > > > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > > > it should be splitted between nuttx and apps-repos and
> > use
> > > > > POSIX
> > > > > > > > > > > implementation as much as possible. We are focused on
> > > > standards
> > > > > > and
> > > > > > > > > > > compatibility.
> > > > > > > > > > >
> > > > > > > > > > > Another concern is the license which does not match our
> > ASF
> > > > one
> > > > > > and
> > > > > > > > > does
> > > > > > > > > > > not include any LICENSE file additions to clarify the
> > > > compiance
> > > > > > > > aspect
> > > > > > > > > > >
> > > > > > > > > > > Best regards
> > > > > > > > > > > Alin J
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > > > xiaoxiang781216@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > > > magicdcps@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > So the real reason you've been objecting to my
> > proposal
> > > > is
> > > > > > that
> > > > > > > > > your
> > > > > > > > > > team
> > > > > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you can give me a clear timeline for when your
> > > > > > > implementation
> > > > > > > > > > will be
> > > > > > > > > > > > > submitted upstream, I'm happy to withdraw my PR and
> > let
> > > > > your
> > > > > > > code
> > > > > > > > > > serve
> > > > > > > > > > > > as
> > > > > > > > > > > > > the baseline. I'm not here to fight over ownership
> of
> > > the
> > > > > > > > Bluetooth
> > > > > > > > > > > > stack.
> > > > > > > > > > > > > My only motivation is that NuttX's lack of a
> capable
> > > > > > Bluetooth
> > > > > > > > > stack
> > > > > > > > > > is
> > > > > > > > > > > > > driving every developer toward Zephyr — and as a
> PMC
> > > > > member,
> > > > > > I
> > > > > > > > > think
> > > > > > > > > > you
> > > > > > > > > > > > > should be asking yourselves why this gap has
> remained
> > > > > > unfilled
> > > > > > > > for
> > > > > > > > > so
> > > > > > > > > > > > long.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > I object to landing the whole bluetooth stack into
> > kernel
> > > > > space
> > > > > > > > > > directly
> > > > > > > > > > > > either yours and ours .
> > > > > > > > > > > > This is the same feeling from raiden00pl too, let's
> see
> > > > other
> > > > > > > > > people's
> > > > > > > > > > > > opinions here.
> > > > > > > > > > > > But it's fine for me to host the whole code in
> > > > nuttx-apps.git
> > > > > > and
> > > > > > > > > > refactor
> > > > > > > > > > > > components to kernel
> > > > > > > > > > > > space step by step.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > As for the current PR, I'll remove the shell
> > components
> > > > > from
> > > > > > > the
> > > > > > > > > > stack
> > > > > > > > > > > > and
> > > > > > > > > > > > > move them into apps/ where they belong. The base
> > > profiles
> > > > > > > (A2DP,
> > > > > > > > > BLE)
> > > > > > > > > > > > will
> > > > > > > > > > > > > stay in libc —
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > The architecture is wrong to host any bluetooth
> > profile
> > > in
> > > > > > libc.
> > > > > > > > > > > >
> > > > > > > > > > > > in flat build mode this gives a significant
> performance
> > > > > > > > > > > > > boost to the overall stack, which is the primary
> > > > deployment
> > > > > > > model
> > > > > > > > > for
> > > > > > > > > > > > most
> > > > > > > > > > > > > NuttX devices.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > Performance should remain the same whether the base
> > > profile
> > > > > is
> > > > > > > > hosted
> > > > > > > > > > in
> > > > > > > > > > > > libc or apps,
> > > > > > > > > > > > could you point out any technical reason which
> impacts
> > > the
> > > > > > > > > performance
> > > > > > > > > > in
> > > > > > > > > > > > the flat mode?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > A few additional data points regarding our
> timeline:
> > > our
> > > > > > > product
> > > > > > > > is
> > > > > > > > > > > > > scheduled for release in December, and Bluetooth
> SIG
> > > > > > > > certification
> > > > > > > > > is
> > > > > > > > > > > > > already in progress — we expect to receive it
> around
> > > > > > November.
> > > > > > > If
> > > > > > > > > the
> > > > > > > > > > > > > baseline were to switch to your team's stack with
> its
> > > > > > different
> > > > > > > > > > > > > architecture, that certification cycle would need
> to
> > be
> > > > > > > repeated,
> > > > > > > > > > which
> > > > > > > > > > > > is
> > > > > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Xiang Xiao <xi...@gmail.com>
> > 于2026年10月16日周五
> > > > > > 15:08写道：
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > > > magicdcps@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Regarding your point about the NimBLE port
> using
> > > the
> > > > > > POSIX
> > > > > > > > API
> > > > > > > > > —
> > > > > > > > > > yes,
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > uses POSIX, but there are real issues with the
> > > > current
> > > > > > > > > > implementation
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real
> > critical
> > > > > > section
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This is a mutex, not a critical section. It
> does
> > > not
> > > > > > > disable
> > > > > > > > > > > > interrupts
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > preemption — an ISR can still fire and corrupt
> > data
> > > > > that
> > > > > > > the
> > > > > > > > > > > > "critical
> > > > > > > > > > > > > > > section" was supposed to protect. On top of
> that,
> > > > > using a
> > > > > > > > mutex
> > > > > > > > > > opens
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > door to ABBA deadlocks when combined with any
> > other
> > > > > lock
> > > > > > > held
> > > > > > > > > > inside
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > critical region:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) →
> > try
> > > > > > > > lock(mutex
> > > > > > > > > > M) ←
> > > > > > > > > > > > > > blocked
> > > > > > > > > > > > > > > by B
> > > > > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > > > > lock(s_mutex) ←
> > > > > > > > > > blocked by
> > > > > > > > > > > > A
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Compare this with the FreeRTOS port, which
> > > correctly
> > > > > uses
> > > > > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical()
> (i.e.,
> > > > > > actually
> > > > > > > > > > disabling
> > > > > > > > > > > > > > > scheduling/preemption). The current NuttX port
> > > simply
> > > > > > does
> > > > > > > > not
> > > > > > > > > > meet
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > semantic contract that the NimBLE stack expects
> > > from
> > > > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > > > 2. Time subsystem uses clock_gettime instead of
> > > > kernel
> > > > > > tick
> > > > > > > > > APIs
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > > > ...),
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > involves a syscall and floating-point
> arithmetic
> > on
> > > > > every
> > > > > > > > call.
> > > > > > > > > > In a
> > > > > > > > > > > > > BLE
> > > > > > > > > > > > > > > stack where timestamps and timing are on the
> hot
> > > > path,
> > > > > > this
> > > > > > > > > adds
> > > > > > > > > > > > > > measurable
> > > > > > > > > > > > > > > overhead compared to accessing the kernel tick
> > > > counter
> > > > > > > > > directly.
> > > > > > > > > > > > > > > 3. Others are already using the kernel
> approach —
> > > and
> > > > > for
> > > > > > > > good
> > > > > > > > > > reason
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack
> > > (zblue)
> > > > > for
> > > > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX for
> > the
> > > > > > > > > > > > performance-critical
> > > > > > > > > > > > > > > paths:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This isn't an academic exercise — it's a
> > production
> > > > > > choice.
> > > > > > > > > They
> > > > > > > > > > > > > > recognized
> > > > > > > > > > > > > > > that a BLE stack needs tight integration with
> the
> > > OS
> > > > > > timer
> > > > > > > > > > subsystem,
> > > > > > > > > > > > > > > direct access to critical section primitives,
> and
> > > > > > efficient
> > > > > > > > > event
> > > > > > > > > > > > > > delivery,
> > > > > > > > > > > > > > > none of which POSIX provides well in this
> > context.
> > > > > > > > > > > > > > > My question
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If other organizations are already using a more
> > > > > > performant,
> > > > > > > > > > > > > > architecturally
> > > > > > > > > > > > > > > correct kernel-level integration for their BLE
> > > stacks
> > > > > on
> > > > > > > > NuttX,
> > > > > > > > > > why
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > we be told that we must use the slower, less
> > > correct
> > > > > > POSIX
> > > > > > > > > path?
> > > > > > > > > > > > > NuttX's
> > > > > > > > > > > > > > > POSIX compliance is valuable, but it shouldn't
> > come
> > > > at
> > > > > > the
> > > > > > > > cost
> > > > > > > > > > of
> > > > > > > > > > > > > > shipping
> > > > > > > > > > > > > > > a BLE stack with a broken critical section
> > > primitive.
> > > > > > There
> > > > > > > > > > should be
> > > > > > > > > > > > > > room
> > > > > > > > > > > > > > > for both approaches, and the decision should be
> > > > driven
> > > > > by
> > > > > > > > > > technical
> > > > > > > > > > > > > > merit,
> > > > > > > > > > > > > > > not by treating POSIX as the only acceptable
> > > answer.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't object to moving the key bluetooth stack
> to
> > > > > kernel
> > > > > > > > space
> > > > > > > > > > like
> > > > > > > > > > > > how
> > > > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is
> far
> > to
> > > > > move
> > > > > > > > > entirely
> > > > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > > > If I low my quality bar, I have requested my
> > teammate
> > > > to
> > > > > > > > upstream
> > > > > > > > > > our
> > > > > > > > > > > > > > implementation:
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > > since much work needs to be done before it can
> > > achieve
> > > > > the
> > > > > > > > > quality
> > > > > > > > > > > > > > upstream.
> > > > > > > > > > > > > > BTW, many zephyr class BT features are developed
> by
> > > my
> > > > > team
> > > > > > > and
> > > > > > > > > > > > upstream
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > > > If considering the quality, our version is much
> > > better
> > > > > > since:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification
> > at
> > > > > > 2026.06
> > > > > > > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alan,
Yes, I agree that we need to find a middle ground and make sure the
integration does not block the existing Bluetooth solutions in NuttX.
From the current implementation, I don't think this zblue-based stack
conflicts with NimBLE or with the existing in-tree BLE stack. They can be
selected independently through Kconfig. For example:
- CONFIG_BT Enables the new zblue-based host stack currently added by
this PR.
- CONFIG_WIRELESS_BLUETOOTH
- CONFIG_WIRELESS_BLUETOOTH_HOST Enable the existing NuttX BLE stack
under wireless/bluetooth.
- CONFIG_NIMBLE Enables the userspace NimBLE stack when that stack is
used from apps.
The lower-level Bluetooth controller / transport drivers are also separate,
for example:
- CONFIG_BLUETOOTH_UART
- CONFIG_BLUETOOTH_RPMSG
- CONFIG_BLUETOOTH_NULL
So I think it is possible to make the three options coexist on NuttX, as
long as we keep the host-stack selection separated and avoid enabling two
host stacks for the same controller path at the same time. If needed, we
can also make this more explicit by adding a Kconfig choice or mutual
exclusion between the host stacks.
Regarding the location, I understand your point about libs/zblue. However,
for the initial version, I still think keeping the full stack under net/bt
is the safer integration path.
The reason is that splitting it into libs/zblue is not only a directory
rename. To do that correctly, we need to isolate each profile and data path
according to its own characteristics. Some profiles are not just pure
userspace library logic. For example, SCO and LE Audio / ISO have
lower-level data paths. On Linux, part of this kind of traffic is handled
or forwarded by the kernel side. So if we move everything to libs/zblue too
early, we may create an artificial boundary that is not correct for those
lower-level profiles.
My suggestion is:
1. Keep the initial version integrated under net/bt, so the controller,
HCI, L2CAP, ISO/SCO and profile paths can work correctly first.
2. Make the stack name clear as zblue if the community prefers that, so
it is not presented as replacing the existing NuttX BLE stack.
3. Keep the Kconfig separation so users can choose between:
- zblue-based stack,
- existing NuttX BLE stack,
- NimBLE userspace stack.
4. After the initial integration is stable, we can evaluate moving or
splitting parts into libs/zblue profile by profile, where the boundary is
technically clear.
So yes, I think it is possible to modify the PR to let both stacks plus
NimBLE work on NuttX without interfering with each other. I just think
doing a full libs/zblue separation as the first step may be risky,
especially for the lower-level profiles and audio-related paths.
Does this direction sound acceptable to you?
BR,
Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 19:32写道：
> Hi Anchao,
>
> Yes, I think having a complete BLE stack like zblue is a good idea.
>
> But we need to find a middle ground for correct integration.
>
> Let's do this: add zblue to libs/zglue and maintain a proper separation to
> allow room for the existing BLE stack on NuttX to evolve.
>
> Just assuming that not updating/synchroning zblue with Zephyr's zblue will
> be enough for them to become different entities seems incorrect.
>
> The amount of code is very large, so even after decades they will share
> enough of their "DNA" that a virus will be able to infect both.
>
> Do you think it is possible to modify your PR to let both stacks (+ NimBLE
> userspace stack) work on NuttX without one interfering on the other?
>
> BR,
>
> Alan
>
> On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com> wrote:
>
> > Hi Alan,
> >
> >
> >
> > Thank you for the detailed analysis.
> >
> >
> >
> > I understand your concern. The current code structure is indeed still
> very
> >
> > close to Zephyr's Bluetooth stack, and the compatibility layer is
> currently
> >
> > quite thin. However, from the long-term technical direction, our
> intention
> > is
> > not to keep doing long-term synchronization with Zephyr. Instead, we plan
> > to
> > quickly feed back the related issues and improvements to the NuttX
> > community
> > during the integration and evolution process.
> >
> >
> >
> > Regarding the naming concern, I think it is reasonable to call it zblue
> >
> > temporarily, since the current implementation is still largely based on
> >
> > Zephyr's Bluetooth stack. If the stack evolves later with a new code
> > structure
> > and clearer NuttX-specific architecture, we can further evaluate whether
> a
> >
> > different name would be more appropriate at that time.
> >
> >
> >
> > Does that sound reasonable to you?
> >
> >
> >
> > BR,
> >
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> >
> > > Hi Anchao,
> > >
> > > I used Claude to help compare the code and here are the reasons to call
> > it
> > > zblue instead of libs/bt:
> > >
> > > Almost all of this PR is Zephyr's Bluetooth stack
> > > ("zblue"), reformatted to NuttX style. The part that doesn't come from
> > > Zephyr is
> > > a thin compatibility layer that makes the Zephyr kernel calls work on
> > > NuttX.
> > >
> > > I pulled all 539 new files (400,450 lines) and compared them against
> > > several
> > > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it matches
> > > better
> > > than Zephyr's current main branch. So the PR looks like a snapshot of
> > zblue
> > > from the last few weeks.
> > >
> > > Results
> > >
> > > Function by function (7,716 functions):
> > >
> > > Class: Identical
> > > Functions: 5,411 (70%)
> > > Lines: 140,189
> > > Meaning: Exactly the same code as Zephyr. Only indentation and braces
> > > differ.
> > > ────────────────────────────────────────
> > > Class: Renames only
> > > Functions: 1,515 (20%)
> > > Lines: 60,863
> > > Meaning: The only changes are API renames that recur across the whole
> > PR:
> > > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> > sys_slist_*→list_*,
> > > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read
> > > ────────────────────────────────────────
> > > Class: Modified
> > > Functions: 584 (8%)
> > > Lines: 33,693
> > > Meaning: Clearly the Zephyr function, plus some edits specific to
> that
> > > function
> > > ────────────────────────────────────────
> > > Class: Not from Zephyr
> > > Functions: 206 (3%)
> > > Lines: 2,734
> > > Meaning: NuttX glue code
> > >
> > > Whole files, including headers:
> > > - On average, 96.9% of each file's code also appears in its Zephyr
> > > counterpart.
> > > - 434 of the 539 files are ≥90% the same as Zephyr; together they
> hold
> > > 375k of
> > > the 400k lines.
> > > - 75% of the comment text, including the Doxygen docs, is
> word-for-word
> > > Zephyr.
> > >
> > > What's actually new:
> > > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c,
> mem_slab.c,
> > > fs.c,
> > > sections/defines.c, hci_driver.c), which provides k_work, k_queue
> and
> > > similar
> > > Zephyr calls on top of NuttX.
> > > - Part of mm/net_buf.
> > > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > > - hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig.
> > >
> > >
> > > So, only 3% of the code is new (this includes the code in sim:bt that
> > must
> > > be new).
> > >
> > > So, reusing the zblue from Zephyr and calling it something else isn't
> > > right; it's like the zbus that Jorge brought from Zephyr, where calling
> > it
> > > NXBus doesn't seem appropriate.
> > >
> > > Besides that, as I said before using ZBlue as our official BT Stack
> will
> > > significantly increase the shared code between NuttX and Zephyr, which
> > > could be dangerous.
> > >
> > > As I said, I not against adding ZBlue to NuttX, but at least make it
> > clear
> > > that it is ZBlue and should be an alternative stack (like NimBLE) not
> the
> > > official NuttX BLE Stack.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > Thanks for the comments and suggestions.
> > > >
> > > > For the first stage, I would prefer to keep the Bluetooth host stack
> > > > supported only in FLAT mode. Supporting Protected and Kernel modes
> > > requires
> > > > a much deeper rework of the stack and its interfaces, especially
> around
> > > the
> > > > boundary between kernel space and user space. I do not think it is a
> > good
> > > > idea to introduce such large architectural changes in this first
> step.
> > > >
> > > > Our current plan is to complete Protected/Kernel mode support in a
> > second
> > > > stage, after the basic stack integration is reviewed and stabilized.
> > This
> > > > should make the initial review and integration much more manageable.
> > > >
> > > > Regarding the library name, I still prefer to use libs/libbt.
> Although
> > > the
> > > > current code is based on Zephyr's zblue, the goal is to maintain it
> as
> > an
> > > > independent NuttX Bluetooth host stack going forward, rather than
> > keeping
> > > > it as a direct Zephyr fork forever. In that sense, I think libbt is a
> > > > better long-term name.
> > > >
> > > > Also, the current NuttX Bluetooth profiles are not implemented in the
> > > > kernel, and we do not plan to move the native NuttX Bluetooth stack
> > > > profiles into the kernel either. Once Protected/Kernel mode support
> is
> > > > added for this stack in the future, this implementation is expected
> to
> > > > replace the previous approach. For this reason, I think keeping the
> > stack
> > > > under libbt is still more appropriate.
> > > >
> > > > About splitting the PR: this PR is already the result of squashing
> more
> > > > than one hundred commits. Most of those commits are
> compatibility-layer
> > > > adjustments, coding style cleanup, and mechanical changes needed to
> > make
> > > > the stack build in NuttX. Asking reviewers to review each of those
> > > commits
> > > > separately would probably cost everyone more time.
> > > >
> > > > Splitting the full Bluetooth stack by profile is also not very
> > practical
> > > at
> > > > the moment, because there are no dedicated maintainers for each
> > > individual
> > > > Bluetooth profile area in NuttX yet. Therefore, I think the current
> > form
> > > is
> > > > probably the most reasonable way to review and integrate the stack
> as a
> > > > whole.
> > > >
> > > > One more update: I have removed all shell-related code from
> > > > https://github.com/apache/nuttx/pull/20686. The plan is to move
> those
> > > > shell
> > > > commands to apps later. With this change, the current Bluetooth stack
> > no
> > > > longer contains any user-space shell code, so I think this is now a
> > > better
> > > > point for review.
> > > >
> > > > Best regards,
> > > >
> > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > > >
> > > > > Hi An Chao,
> > > > >
> > > > > Isn't it possible to have a similar implementation that works for
> > FLAT,
> > > > > Protected and Kernel modes?
> > > > >
> > > > > This way the maintenance will be easier. Only small kernel-specific
> > > parts
> > > > > will remain there (as Raiden and Xiang proposed).
> > > > >
> > > > > Suggestion: instead of naming it libs/libbt/, it would be better to
> > use
> > > > > libs/zblue to make it clear that it is a zblue port from Zephyr.
> > > > >
> > > > > Let's use libs/libbt only for NuttX-specific (native) code.
> > > > >
> > > > > And as I said, it is better to easily isolate the code that came
> from
> > > > > Zephyr's zblue.
> > > > >
> > > > > This way the user could select the Bluetooth stack they want
> without
> > > > having
> > > > > code from the other stack attached to it.
> > > > >
> > > > > Also I suggest you to break your PR into smaller PRs; a single PR
> > > > changing
> > > > > more than 660K LoC is very massive.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com>
> wrote:
> > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > > Thank you for the thoughtful perspective and for engaging in the
> > > > > > discussion.
> > > > > >
> > > > > > On security: we will maintain the Bluetooth stack ourselves and
> > take
> > > > > > responsibility for tracking and fixing vulnerabilities. I'm also
> > > > > confident
> > > > > > that Xiaomi will contribute back on security issues given their
> > > ongoing
> > > > > > investment in this codebase. This isn't a blind import — it's
> code
> > > that
> > > > > has
> > > > > > active, committed maintainers behind it.
> > > > > >
> > > > > > Regarding the history with Greg: you're right that we discussed
> > this
> > > > > years
> > > > > > ago. But there's an important distinction — that earlier proposal
> > > > placed
> > > > > > the stack entirely in userspace. It did nothing to strengthen
> > NuttX's
> > > > > > kernel-level Bluetooth support. That's precisely why I'm back
> now,
> > > > > > providing a kernel implementation this time around, which is
> what I
> > > > > > committed to back then. Feel free to search the mailing list
> > > archives —
> > > > > the
> > > > > > NuttX native Bluetooth stack will evolve from this baseline going
> > > > > forward.
> > > > > >
> > > > > > This implementation does not affect existing Bluetooth stacks in
> > any
> > > > way.
> > > > > > Users can still choose NimBLE, the current NuttX BLE stack, or
> any
> > > > other
> > > > > > solution. This is an additional option, not a replacement. The
> goal
> > > is
> > > > to
> > > > > > give NuttX users more choices, not fewer.
> > > > > >
> > > > > > One more update: I just spoke with Xiaoxiang and we've reached
> some
> > > > > common
> > > > > > ground. He's no longer opposed to the current stack
> implementation
> > > and
> > > > > > agrees that the focus should be on proper structuring. Here's the
> > > plan
> > > > > > going forward:
> > > > > >
> > > > > > 1. Unused shell code will be moved out of the stack and into
> > > apps/,
> > > > > > running entirely in userspace.
> > > > > > 2. Bluetooth profiles will be migrated to libs/libbt/, where
> > we'll
> > > > > > provide two OS API backends: a POSIX API implementation (for
> > > > > > kernel/protected builds) and a NuttX kernel API implementation
> > > (for
> > > > > flat
> > > > > > mode).
> > > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > > >
> > > > > > This should address the architectural concerns while preserving
> the
> > > > > > performance path for flat-mode deployments.
> > > > > >
> > > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > > > >
> > > > > > > Hi An Chao,
> > > > > > >
> > > > > > > Thank you for trying to improve the NuttX Bluetooth support.
> And
> > > > thank
> > > > > > you
> > > > > > > to bring this discussion here to let more people give their
> > > opinion.
> > > > > > >
> > > > > > > I think most of the concerns raised by Xiang and Raiden
> (Mateusz)
> > > are
> > > > > > > important and need to be addressed.
> > > > > > >
> > > > > > > As I said at GitHub PR I think a main concern here is using the
> > > same
> > > > > > > Bluetooth stack used on Zephyr, not because it is a bad stack
> (of
> > > > > course
> > > > > > it
> > > > > > > is not, it was developed by experts on Bluetooth area), but
> > because
> > > > we
> > > > > > are
> > > > > > > adding the same surface area of attack from Zephyr on NuttX.
> > > > > > >
> > > > > > > That means any security vulnerability affecting Zephyr BLE
> stack
> > > will
> > > > > > > affect NuttX. It remove the protection that a companies could
> > > obtain
> > > > > when
> > > > > > > using different RTOSs.
> > > > > > >
> > > > > > > Also, if my memory still serving me, I think Xiaomi team (you
> was
> > > > there
> > > > > > at
> > > > > > > that time) already tried to submit their initial port of Zephyr
> > BLE
> > > > > stack
> > > > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > > > >
> > > > > > > His suggestion was to improve our BLE stack, that in fact has
> the
> > > > same
> > > > > > > origin of the Zephyr BLE stack (both came from a BLE stack from
> > > Intel
> > > > > > > released as BSD license at that time).
> > > > > > >
> > > > > > > I'm not against including the Zephyr BLE stack, but it should
> be
> > > > > > > selectable. Ideally the user should select if he/she wants to
> use
> > > > > NimBLE,
> > > > > > > Zephyr or NuttX native BLE stack.
> > > > > > >
> > > > > > > BR,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > > On Friday, October 16, 2026, chao an <ma...@gmail.com>
> > wrote:
> > > > > > >
> > > > > > > > Hi, Tomek,
> > > > > > > >
> > > > > > > > Thanks for the thoughtful input and the FreeBSD references —
> > > those
> > > > > are
> > > > > > > very
> > > > > > > > relevant to where we're heading.
> > > > > > > >
> > > > > > > > Just to set the context: NuttX's current Bluetooth stack only
> > > > > supports
> > > > > > > BLE.
> > > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all
> > > missing.
> > > > > This
> > > > > > > is
> > > > > > > > exactly why we want to bring a more complete Bluetooth stack
> to
> > > > > NuttX —
> > > > > > > to
> > > > > > > > catch up with what mainstream RTOS communities already offer.
> > > > > > > >
> > > > > > > > I actually agree with the FreeBSD/Apple architecture you
> > > > referenced.
> > > > > > Our
> > > > > > > > end-state plan is similar: the L2CAP and HCI layers will live
> > in
> > > > the
> > > > > > > > kernel, and a bluetoothd-style daemon will be implemented in
> > > libc,
> > > > > > > managing
> > > > > > > > profiles and higher-level protocols. This gives us a clean
> > > > > separation —
> > > > > > > > transport in the kernel, policy and profiles in userspace —
> > much
> > > > like
> > > > > > how
> > > > > > > > FreeBSD's ng_hci / hccontrol split works. The current PR is
> > > Phase 1
> > > > > of
> > > > > > > > getting there incrementally.
> > > > > > > >
> > > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > > > >
> > > > > > > > > Thank you An Chao for this proposition, work, and
> discussion
> > > :-)
> > > > > > > > >
> > > > > > > > > For sure it would be nice to have a BT stack with more
> > > features!
> > > > > The
> > > > > > > > > BT has known issue of having different implementations of
> the
> > > > stack
> > > > > > on
> > > > > > > > > different RTOS / OS / platforms, which is a known issue,
> and
> > > > kinda
> > > > > > > > > mess because there is no common standard / approach /
> > > > > implementation,
> > > > > > > > > unfortunately around something that is supposed to be based
> > on
> > > a
> > > > > > > > > common standard.
> > > > > > > > >
> > > > > > > > > Having common BT stack with other popular RTOS may make
> > > > portability
> > > > > > > > > easier and developers move to NuttX in some cases.
> > > > > > > > >
> > > > > > > > > I understand that we are talking about this solution?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > > connectivity/bluetooth/index.html
> > > > > > > > >
> > > > > > > > > In a perfect situation we would want to have modular
> > > > implementation
> > > > > > in
> > > > > > > > > nuttx-apps just like nimble. This is pointed out by Xiang,
> > > > Raiden,
> > > > > > and
> > > > > > > > > Alin already. But I understand some things may be hard to
> > > > implement
> > > > > > > > > that way. I will follow the consensus here when ready, I
> have
> > > no
> > > > > > > > > strong opinion here, except any BT stack I touched before
> > was a
> > > > > mess
> > > > > > > > > and I hope we can work out at least something decent :-P
> > > > > > > > >
> > > > > > > > > A bit offtopic but for kernel build we can take a look at
> > quite
> > > > old
> > > > > > > > > Bluetooth implementation on FreeBSD, where radio is
> provided
> > by
> > > > > > ng_ubt
> > > > > > > > > (lower half in out case), then upper half uses standard
> HCI.
> > > > Maybe
> > > > > > > > > something like this is possible in NuttX?
> > > > > > > > >
> > > > > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > > 4.
> > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > > 5.
> > > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > > >
> > > > > > > > > Here is a quick overview article on the Bluetooth
> > > implementation
> > > > in
> > > > > > > > > FreeBSD and Apple:
> > > > > > > > >
> > > > > > > > >
> https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > > >
> > > > > > > > > Again it will be very nice to have fully featured BT stack
> in
> > > > NuttX
> > > > > > > > > and I hope we can sort out the best possible porting
> > > > implementation
> > > > > > > > > :-)
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > > >
> > > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > > jerpelea@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > thanks Xiao and Raiden for your technical opinions which
> I
> > > also
> > > > > > share
> > > > > > > > so
> > > > > > > > > I
> > > > > > > > > > will not iterate them again.
> > > > > > > > > >
> > > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > > it should be splitted between nuttx and apps-repos and
> use
> > > > POSIX
> > > > > > > > > > implementation as much as possible. We are focused on
> > > standards
> > > > > and
> > > > > > > > > > compatibility.
> > > > > > > > > >
> > > > > > > > > > Another concern is the license which does not match our
> ASF
> > > one
> > > > > and
> > > > > > > > does
> > > > > > > > > > not include any LICENSE file additions to clarify the
> > > compiance
> > > > > > > aspect
> > > > > > > > > >
> > > > > > > > > > Best regards
> > > > > > > > > > Alin J
> > > > > > > > > >
> > > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > > xiaoxiang781216@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > > magicdcps@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > So the real reason you've been objecting to my
> proposal
> > > is
> > > > > that
> > > > > > > > your
> > > > > > > > > team
> > > > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > > > >
> > > > > > > > > > > > If you can give me a clear timeline for when your
> > > > > > implementation
> > > > > > > > > will be
> > > > > > > > > > > > submitted upstream, I'm happy to withdraw my PR and
> let
> > > > your
> > > > > > code
> > > > > > > > > serve
> > > > > > > > > > > as
> > > > > > > > > > > > the baseline. I'm not here to fight over ownership of
> > the
> > > > > > > Bluetooth
> > > > > > > > > > > stack.
> > > > > > > > > > > > My only motivation is that NuttX's lack of a capable
> > > > > Bluetooth
> > > > > > > > stack
> > > > > > > > > is
> > > > > > > > > > > > driving every developer toward Zephyr — and as a PMC
> > > > member,
> > > > > I
> > > > > > > > think
> > > > > > > > > you
> > > > > > > > > > > > should be asking yourselves why this gap has remained
> > > > > unfilled
> > > > > > > for
> > > > > > > > so
> > > > > > > > > > > long.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > I object to landing the whole bluetooth stack into
> kernel
> > > > space
> > > > > > > > > directly
> > > > > > > > > > > either yours and ours .
> > > > > > > > > > > This is the same feeling from raiden00pl too, let's see
> > > other
> > > > > > > > people's
> > > > > > > > > > > opinions here.
> > > > > > > > > > > But it's fine for me to host the whole code in
> > > nuttx-apps.git
> > > > > and
> > > > > > > > > refactor
> > > > > > > > > > > components to kernel
> > > > > > > > > > > space step by step.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > As for the current PR, I'll remove the shell
> components
> > > > from
> > > > > > the
> > > > > > > > > stack
> > > > > > > > > > > and
> > > > > > > > > > > > move them into apps/ where they belong. The base
> > profiles
> > > > > > (A2DP,
> > > > > > > > BLE)
> > > > > > > > > > > will
> > > > > > > > > > > > stay in libc —
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The architecture is wrong to host any bluetooth
> profile
> > in
> > > > > libc.
> > > > > > > > > > >
> > > > > > > > > > > in flat build mode this gives a significant performance
> > > > > > > > > > > > boost to the overall stack, which is the primary
> > > deployment
> > > > > > model
> > > > > > > > for
> > > > > > > > > > > most
> > > > > > > > > > > > NuttX devices.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > Performance should remain the same whether the base
> > profile
> > > > is
> > > > > > > hosted
> > > > > > > > > in
> > > > > > > > > > > libc or apps,
> > > > > > > > > > > could you point out any technical reason which impacts
> > the
> > > > > > > > performance
> > > > > > > > > in
> > > > > > > > > > > the flat mode?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > A few additional data points regarding our timeline:
> > our
> > > > > > product
> > > > > > > is
> > > > > > > > > > > > scheduled for release in December, and Bluetooth SIG
> > > > > > > certification
> > > > > > > > is
> > > > > > > > > > > > already in progress — we expect to receive it around
> > > > > November.
> > > > > > If
> > > > > > > > the
> > > > > > > > > > > > baseline were to switch to your team's stack with its
> > > > > different
> > > > > > > > > > > > architecture, that certification cycle would need to
> be
> > > > > > repeated,
> > > > > > > > > which
> > > > > > > > > > > is
> > > > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > > > >
> > > > > > > > > > > > Xiang Xiao <xi...@gmail.com>
> 于2026年10月16日周五
> > > > > 15:08写道：
> > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > > magicdcps@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regarding your point about the NimBLE port using
> > the
> > > > > POSIX
> > > > > > > API
> > > > > > > > —
> > > > > > > > > yes,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > uses POSIX, but there are real issues with the
> > > current
> > > > > > > > > implementation
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real
> critical
> > > > > section
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > > {
> > > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is a mutex, not a critical section. It does
> > not
> > > > > > disable
> > > > > > > > > > > interrupts
> > > > > > > > > > > > > or
> > > > > > > > > > > > > > preemption — an ISR can still fire and corrupt
> data
> > > > that
> > > > > > the
> > > > > > > > > > > "critical
> > > > > > > > > > > > > > section" was supposed to protect. On top of that,
> > > > using a
> > > > > > > mutex
> > > > > > > > > opens
> > > > > > > > > > > > the
> > > > > > > > > > > > > > door to ABBA deadlocks when combined with any
> other
> > > > lock
> > > > > > held
> > > > > > > > > inside
> > > > > > > > > > > > the
> > > > > > > > > > > > > > critical region:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) →
> try
> > > > > > > lock(mutex
> > > > > > > > > M) ←
> > > > > > > > > > > > > blocked
> > > > > > > > > > > > > > by B
> > > > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > > > lock(s_mutex) ←
> > > > > > > > > blocked by
> > > > > > > > > > > A
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Compare this with the FreeRTOS port, which
> > correctly
> > > > uses
> > > > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e.,
> > > > > actually
> > > > > > > > > disabling
> > > > > > > > > > > > > > scheduling/preemption). The current NuttX port
> > simply
> > > > > does
> > > > > > > not
> > > > > > > > > meet
> > > > > > > > > > > the
> > > > > > > > > > > > > > semantic contract that the NimBLE stack expects
> > from
> > > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > > 2. Time subsystem uses clock_gettime instead of
> > > kernel
> > > > > tick
> > > > > > > > APIs
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > > ...),
> > > > > > > > > > > > > which
> > > > > > > > > > > > > > involves a syscall and floating-point arithmetic
> on
> > > > every
> > > > > > > call.
> > > > > > > > > In a
> > > > > > > > > > > > BLE
> > > > > > > > > > > > > > stack where timestamps and timing are on the hot
> > > path,
> > > > > this
> > > > > > > > adds
> > > > > > > > > > > > > measurable
> > > > > > > > > > > > > > overhead compared to accessing the kernel tick
> > > counter
> > > > > > > > directly.
> > > > > > > > > > > > > > 3. Others are already using the kernel approach —
> > and
> > > > for
> > > > > > > good
> > > > > > > > > reason
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack
> > (zblue)
> > > > for
> > > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX for
> the
> > > > > > > > > > > performance-critical
> > > > > > > > > > > > > > paths:
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This isn't an academic exercise — it's a
> production
> > > > > choice.
> > > > > > > > They
> > > > > > > > > > > > > recognized
> > > > > > > > > > > > > > that a BLE stack needs tight integration with the
> > OS
> > > > > timer
> > > > > > > > > subsystem,
> > > > > > > > > > > > > > direct access to critical section primitives, and
> > > > > efficient
> > > > > > > > event
> > > > > > > > > > > > > delivery,
> > > > > > > > > > > > > > none of which POSIX provides well in this
> context.
> > > > > > > > > > > > > > My question
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If other organizations are already using a more
> > > > > performant,
> > > > > > > > > > > > > architecturally
> > > > > > > > > > > > > > correct kernel-level integration for their BLE
> > stacks
> > > > on
> > > > > > > NuttX,
> > > > > > > > > why
> > > > > > > > > > > > > should
> > > > > > > > > > > > > > we be told that we must use the slower, less
> > correct
> > > > > POSIX
> > > > > > > > path?
> > > > > > > > > > > > NuttX's
> > > > > > > > > > > > > > POSIX compliance is valuable, but it shouldn't
> come
> > > at
> > > > > the
> > > > > > > cost
> > > > > > > > > of
> > > > > > > > > > > > > shipping
> > > > > > > > > > > > > > a BLE stack with a broken critical section
> > primitive.
> > > > > There
> > > > > > > > > should be
> > > > > > > > > > > > > room
> > > > > > > > > > > > > > for both approaches, and the decision should be
> > > driven
> > > > by
> > > > > > > > > technical
> > > > > > > > > > > > > merit,
> > > > > > > > > > > > > > not by treating POSIX as the only acceptable
> > answer.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > I don't object to moving the key bluetooth stack to
> > > > kernel
> > > > > > > space
> > > > > > > > > like
> > > > > > > > > > > how
> > > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is far
> to
> > > > move
> > > > > > > > entirely
> > > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > > If I low my quality bar, I have requested my
> teammate
> > > to
> > > > > > > upstream
> > > > > > > > > our
> > > > > > > > > > > > > implementation:
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > > since much work needs to be done before it can
> > achieve
> > > > the
> > > > > > > > quality
> > > > > > > > > > > > > upstream.
> > > > > > > > > > > > > BTW, many zephyr class BT features are developed by
> > my
> > > > team
> > > > > > and
> > > > > > > > > > > upstream
> > > > > > > > > > > > to
> > > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > > If considering the quality, our version is much
> > better
> > > > > since:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification
> at
> > > > > 2026.06
> > > > > > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Anchao,
Yes, I think having a complete BLE stack like zblue is a good idea.
But we need to find a middle ground for correct integration.
Let's do this: add zblue to libs/zglue and maintain a proper separation to
allow room for the existing BLE stack on NuttX to evolve.
Just assuming that not updating/synchroning zblue with Zephyr's zblue will
be enough for them to become different entities seems incorrect.
The amount of code is very large, so even after decades they will share
enough of their "DNA" that a virus will be able to infect both.
Do you think it is possible to modify your PR to let both stacks (+ NimBLE
userspace stack) work on NuttX without one interfering on the other?
BR,
Alan
On Thu, Oct 22, 2026 at 12:20 AM chao an <ma...@gmail.com> wrote:
> Hi Alan,
>
>
>
> Thank you for the detailed analysis.
>
>
>
> I understand your concern. The current code structure is indeed still very
>
> close to Zephyr's Bluetooth stack, and the compatibility layer is currently
>
> quite thin. However, from the long-term technical direction, our intention
> is
> not to keep doing long-term synchronization with Zephyr. Instead, we plan
> to
> quickly feed back the related issues and improvements to the NuttX
> community
> during the integration and evolution process.
>
>
>
> Regarding the naming concern, I think it is reasonable to call it zblue
>
> temporarily, since the current implementation is still largely based on
>
> Zephyr's Bluetooth stack. If the stack evolves later with a new code
> structure
> and clearer NuttX-specific architecture, we can further evaluate whether a
>
> different name would be more appropriate at that time.
>
>
>
> Does that sound reasonable to you?
>
>
>
> BR,
>
>
> Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
>
> > Hi Anchao,
> >
> > I used Claude to help compare the code and here are the reasons to call
> it
> > zblue instead of libs/bt:
> >
> > Almost all of this PR is Zephyr's Bluetooth stack
> > ("zblue"), reformatted to NuttX style. The part that doesn't come from
> > Zephyr is
> > a thin compatibility layer that makes the Zephyr kernel calls work on
> > NuttX.
> >
> > I pulled all 539 new files (400,450 lines) and compared them against
> > several
> > Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it matches
> > better
> > than Zephyr's current main branch. So the PR looks like a snapshot of
> zblue
> > from the last few weeks.
> >
> > Results
> >
> > Function by function (7,716 functions):
> >
> > Class: Identical
> > Functions: 5,411 (70%)
> > Lines: 140,189
> > Meaning: Exactly the same code as Zephyr. Only indentation and braces
> > differ.
> > ────────────────────────────────────────
> > Class: Renames only
> > Functions: 1,515 (20%)
> > Lines: 60,863
> > Meaning: The only changes are API renames that recur across the whole
> PR:
> > __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1),
> sys_slist_*→list_*,
> > k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read
> > ────────────────────────────────────────
> > Class: Modified
> > Functions: 584 (8%)
> > Lines: 33,693
> > Meaning: Clearly the Zephyr function, plus some edits specific to that
> > function
> > ────────────────────────────────────────
> > Class: Not from Zephyr
> > Functions: 206 (3%)
> > Lines: 2,734
> > Meaning: NuttX glue code
> >
> > Whole files, including headers:
> > - On average, 96.9% of each file's code also appears in its Zephyr
> > counterpart.
> > - 434 of the 539 files are ≥90% the same as Zephyr; together they hold
> > 375k of
> > the 400k lines.
> > - 75% of the comment text, including the Doxygen docs, is word-for-word
> > Zephyr.
> >
> > What's actually new:
> > - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c, mem_slab.c,
> > fs.c,
> > sections/defines.c, hci_driver.c), which provides k_work, k_queue and
> > similar
> > Zephyr calls on top of NuttX.
> > - Part of mm/net_buf.
> > - bt_nus_auto_start_bt.c, which has been heavily extended.
> > - hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig.
> >
> >
> > So, only 3% of the code is new (this includes the code in sim:bt that
> must
> > be new).
> >
> > So, reusing the zblue from Zephyr and calling it something else isn't
> > right; it's like the zbus that Jorge brought from Zephyr, where calling
> it
> > NXBus doesn't seem appropriate.
> >
> > Besides that, as I said before using ZBlue as our official BT Stack will
> > significantly increase the shared code between NuttX and Zephyr, which
> > could be dangerous.
> >
> > As I said, I not against adding ZBlue to NuttX, but at least make it
> clear
> > that it is ZBlue and should be an alternative stack (like NimBLE) not the
> > official NuttX BLE Stack.
> >
> > BR,
> >
> > Alan
> >
> > On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi Alan,
> > >
> > > Thanks for the comments and suggestions.
> > >
> > > For the first stage, I would prefer to keep the Bluetooth host stack
> > > supported only in FLAT mode. Supporting Protected and Kernel modes
> > requires
> > > a much deeper rework of the stack and its interfaces, especially around
> > the
> > > boundary between kernel space and user space. I do not think it is a
> good
> > > idea to introduce such large architectural changes in this first step.
> > >
> > > Our current plan is to complete Protected/Kernel mode support in a
> second
> > > stage, after the basic stack integration is reviewed and stabilized.
> This
> > > should make the initial review and integration much more manageable.
> > >
> > > Regarding the library name, I still prefer to use libs/libbt. Although
> > the
> > > current code is based on Zephyr's zblue, the goal is to maintain it as
> an
> > > independent NuttX Bluetooth host stack going forward, rather than
> keeping
> > > it as a direct Zephyr fork forever. In that sense, I think libbt is a
> > > better long-term name.
> > >
> > > Also, the current NuttX Bluetooth profiles are not implemented in the
> > > kernel, and we do not plan to move the native NuttX Bluetooth stack
> > > profiles into the kernel either. Once Protected/Kernel mode support is
> > > added for this stack in the future, this implementation is expected to
> > > replace the previous approach. For this reason, I think keeping the
> stack
> > > under libbt is still more appropriate.
> > >
> > > About splitting the PR: this PR is already the result of squashing more
> > > than one hundred commits. Most of those commits are compatibility-layer
> > > adjustments, coding style cleanup, and mechanical changes needed to
> make
> > > the stack build in NuttX. Asking reviewers to review each of those
> > commits
> > > separately would probably cost everyone more time.
> > >
> > > Splitting the full Bluetooth stack by profile is also not very
> practical
> > at
> > > the moment, because there are no dedicated maintainers for each
> > individual
> > > Bluetooth profile area in NuttX yet. Therefore, I think the current
> form
> > is
> > > probably the most reasonable way to review and integrate the stack as a
> > > whole.
> > >
> > > One more update: I have removed all shell-related code from
> > > https://github.com/apache/nuttx/pull/20686. The plan is to move those
> > > shell
> > > commands to apps later. With this change, the current Bluetooth stack
> no
> > > longer contains any user-space shell code, so I think this is now a
> > better
> > > point for review.
> > >
> > > Best regards,
> > >
> > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> > >
> > > > Hi An Chao,
> > > >
> > > > Isn't it possible to have a similar implementation that works for
> FLAT,
> > > > Protected and Kernel modes?
> > > >
> > > > This way the maintenance will be easier. Only small kernel-specific
> > parts
> > > > will remain there (as Raiden and Xiang proposed).
> > > >
> > > > Suggestion: instead of naming it libs/libbt/, it would be better to
> use
> > > > libs/zblue to make it clear that it is a zblue port from Zephyr.
> > > >
> > > > Let's use libs/libbt only for NuttX-specific (native) code.
> > > >
> > > > And as I said, it is better to easily isolate the code that came from
> > > > Zephyr's zblue.
> > > >
> > > > This way the user could select the Bluetooth stack they want without
> > > having
> > > > code from the other stack attached to it.
> > > >
> > > > Also I suggest you to break your PR into smaller PRs; a single PR
> > > changing
> > > > more than 660K LoC is very massive.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com> wrote:
> > > >
> > > > > Hi Alan,
> > > > >
> > > > > Thank you for the thoughtful perspective and for engaging in the
> > > > > discussion.
> > > > >
> > > > > On security: we will maintain the Bluetooth stack ourselves and
> take
> > > > > responsibility for tracking and fixing vulnerabilities. I'm also
> > > > confident
> > > > > that Xiaomi will contribute back on security issues given their
> > ongoing
> > > > > investment in this codebase. This isn't a blind import — it's code
> > that
> > > > has
> > > > > active, committed maintainers behind it.
> > > > >
> > > > > Regarding the history with Greg: you're right that we discussed
> this
> > > > years
> > > > > ago. But there's an important distinction — that earlier proposal
> > > placed
> > > > > the stack entirely in userspace. It did nothing to strengthen
> NuttX's
> > > > > kernel-level Bluetooth support. That's precisely why I'm back now,
> > > > > providing a kernel implementation this time around, which is what I
> > > > > committed to back then. Feel free to search the mailing list
> > archives —
> > > > the
> > > > > NuttX native Bluetooth stack will evolve from this baseline going
> > > > forward.
> > > > >
> > > > > This implementation does not affect existing Bluetooth stacks in
> any
> > > way.
> > > > > Users can still choose NimBLE, the current NuttX BLE stack, or any
> > > other
> > > > > solution. This is an additional option, not a replacement. The goal
> > is
> > > to
> > > > > give NuttX users more choices, not fewer.
> > > > >
> > > > > One more update: I just spoke with Xiaoxiang and we've reached some
> > > > common
> > > > > ground. He's no longer opposed to the current stack implementation
> > and
> > > > > agrees that the focus should be on proper structuring. Here's the
> > plan
> > > > > going forward:
> > > > >
> > > > > 1. Unused shell code will be moved out of the stack and into
> > apps/,
> > > > > running entirely in userspace.
> > > > > 2. Bluetooth profiles will be migrated to libs/libbt/, where
> we'll
> > > > > provide two OS API backends: a POSIX API implementation (for
> > > > > kernel/protected builds) and a NuttX kernel API implementation
> > (for
> > > > flat
> > > > > mode).
> > > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > > >
> > > > > This should address the architectural concerns while preserving the
> > > > > performance path for flat-mode deployments.
> > > > >
> > > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > > >
> > > > > > Hi An Chao,
> > > > > >
> > > > > > Thank you for trying to improve the NuttX Bluetooth support. And
> > > thank
> > > > > you
> > > > > > to bring this discussion here to let more people give their
> > opinion.
> > > > > >
> > > > > > I think most of the concerns raised by Xiang and Raiden (Mateusz)
> > are
> > > > > > important and need to be addressed.
> > > > > >
> > > > > > As I said at GitHub PR I think a main concern here is using the
> > same
> > > > > > Bluetooth stack used on Zephyr, not because it is a bad stack (of
> > > > course
> > > > > it
> > > > > > is not, it was developed by experts on Bluetooth area), but
> because
> > > we
> > > > > are
> > > > > > adding the same surface area of attack from Zephyr on NuttX.
> > > > > >
> > > > > > That means any security vulnerability affecting Zephyr BLE stack
> > will
> > > > > > affect NuttX. It remove the protection that a companies could
> > obtain
> > > > when
> > > > > > using different RTOSs.
> > > > > >
> > > > > > Also, if my memory still serving me, I think Xiaomi team (you was
> > > there
> > > > > at
> > > > > > that time) already tried to submit their initial port of Zephyr
> BLE
> > > > stack
> > > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > > >
> > > > > > His suggestion was to improve our BLE stack, that in fact has the
> > > same
> > > > > > origin of the Zephyr BLE stack (both came from a BLE stack from
> > Intel
> > > > > > released as BSD license at that time).
> > > > > >
> > > > > > I'm not against including the Zephyr BLE stack, but it should be
> > > > > > selectable. Ideally the user should select if he/she wants to use
> > > > NimBLE,
> > > > > > Zephyr or NuttX native BLE stack.
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > > On Friday, October 16, 2026, chao an <ma...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Hi, Tomek,
> > > > > > >
> > > > > > > Thanks for the thoughtful input and the FreeBSD references —
> > those
> > > > are
> > > > > > very
> > > > > > > relevant to where we're heading.
> > > > > > >
> > > > > > > Just to set the context: NuttX's current Bluetooth stack only
> > > > supports
> > > > > > BLE.
> > > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all
> > missing.
> > > > This
> > > > > > is
> > > > > > > exactly why we want to bring a more complete Bluetooth stack to
> > > > NuttX —
> > > > > > to
> > > > > > > catch up with what mainstream RTOS communities already offer.
> > > > > > >
> > > > > > > I actually agree with the FreeBSD/Apple architecture you
> > > referenced.
> > > > > Our
> > > > > > > end-state plan is similar: the L2CAP and HCI layers will live
> in
> > > the
> > > > > > > kernel, and a bluetoothd-style daemon will be implemented in
> > libc,
> > > > > > managing
> > > > > > > profiles and higher-level protocols. This gives us a clean
> > > > separation —
> > > > > > > transport in the kernel, policy and profiles in userspace —
> much
> > > like
> > > > > how
> > > > > > > FreeBSD's ng_hci / hccontrol split works. The current PR is
> > Phase 1
> > > > of
> > > > > > > getting there incrementally.
> > > > > > >
> > > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > > >
> > > > > > > > Thank you An Chao for this proposition, work, and discussion
> > :-)
> > > > > > > >
> > > > > > > > For sure it would be nice to have a BT stack with more
> > features!
> > > > The
> > > > > > > > BT has known issue of having different implementations of the
> > > stack
> > > > > on
> > > > > > > > different RTOS / OS / platforms, which is a known issue, and
> > > kinda
> > > > > > > > mess because there is no common standard / approach /
> > > > implementation,
> > > > > > > > unfortunately around something that is supposed to be based
> on
> > a
> > > > > > > > common standard.
> > > > > > > >
> > > > > > > > Having common BT stack with other popular RTOS may make
> > > portability
> > > > > > > > easier and developers move to NuttX in some cases.
> > > > > > > >
> > > > > > > > I understand that we are talking about this solution?
> > > > > > > >
> > > > > > > >
> > > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > > connectivity/bluetooth/index.html
> > > > > > > >
> > > > > > > > In a perfect situation we would want to have modular
> > > implementation
> > > > > in
> > > > > > > > nuttx-apps just like nimble. This is pointed out by Xiang,
> > > Raiden,
> > > > > and
> > > > > > > > Alin already. But I understand some things may be hard to
> > > implement
> > > > > > > > that way. I will follow the consensus here when ready, I have
> > no
> > > > > > > > strong opinion here, except any BT stack I touched before
> was a
> > > > mess
> > > > > > > > and I hope we can work out at least something decent :-P
> > > > > > > >
> > > > > > > > A bit offtopic but for kernel build we can take a look at
> quite
> > > old
> > > > > > > > Bluetooth implementation on FreeBSD, where radio is provided
> by
> > > > > ng_ubt
> > > > > > > > (lower half in out case), then upper half uses standard HCI.
> > > Maybe
> > > > > > > > something like this is possible in NuttX?
> > > > > > > >
> > > > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > > 4.
> > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > > 5.
> > https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > > >
> > > > > > > > Here is a quick overview article on the Bluetooth
> > implementation
> > > in
> > > > > > > > FreeBSD and Apple:
> > > > > > > >
> > > > > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > > >
> > > > > > > > Again it will be very nice to have fully featured BT stack in
> > > NuttX
> > > > > > > > and I hope we can sort out the best possible porting
> > > implementation
> > > > > > > > :-)
> > > > > > > >
> > > > > > > > --
> > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > >
> > > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > > jerpelea@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > thanks Xiao and Raiden for your technical opinions which I
> > also
> > > > > share
> > > > > > > so
> > > > > > > > I
> > > > > > > > > will not iterate them again.
> > > > > > > > >
> > > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > > it should be splitted between nuttx and apps-repos and use
> > > POSIX
> > > > > > > > > implementation as much as possible. We are focused on
> > standards
> > > > and
> > > > > > > > > compatibility.
> > > > > > > > >
> > > > > > > > > Another concern is the license which does not match our ASF
> > one
> > > > and
> > > > > > > does
> > > > > > > > > not include any LICENSE file additions to clarify the
> > compiance
> > > > > > aspect
> > > > > > > > >
> > > > > > > > > Best regards
> > > > > > > > > Alin J
> > > > > > > > >
> > > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > > xiaoxiang781216@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> > magicdcps@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > So the real reason you've been objecting to my proposal
> > is
> > > > that
> > > > > > > your
> > > > > > > > team
> > > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > > >
> > > > > > > > > > > If you can give me a clear timeline for when your
> > > > > implementation
> > > > > > > > will be
> > > > > > > > > > > submitted upstream, I'm happy to withdraw my PR and let
> > > your
> > > > > code
> > > > > > > > serve
> > > > > > > > > > as
> > > > > > > > > > > the baseline. I'm not here to fight over ownership of
> the
> > > > > > Bluetooth
> > > > > > > > > > stack.
> > > > > > > > > > > My only motivation is that NuttX's lack of a capable
> > > > Bluetooth
> > > > > > > stack
> > > > > > > > is
> > > > > > > > > > > driving every developer toward Zephyr — and as a PMC
> > > member,
> > > > I
> > > > > > > think
> > > > > > > > you
> > > > > > > > > > > should be asking yourselves why this gap has remained
> > > > unfilled
> > > > > > for
> > > > > > > so
> > > > > > > > > > long.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > I object to landing the whole bluetooth stack into kernel
> > > space
> > > > > > > > directly
> > > > > > > > > > either yours and ours .
> > > > > > > > > > This is the same feeling from raiden00pl too, let's see
> > other
> > > > > > > people's
> > > > > > > > > > opinions here.
> > > > > > > > > > But it's fine for me to host the whole code in
> > nuttx-apps.git
> > > > and
> > > > > > > > refactor
> > > > > > > > > > components to kernel
> > > > > > > > > > space step by step.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > As for the current PR, I'll remove the shell components
> > > from
> > > > > the
> > > > > > > > stack
> > > > > > > > > > and
> > > > > > > > > > > move them into apps/ where they belong. The base
> profiles
> > > > > (A2DP,
> > > > > > > BLE)
> > > > > > > > > > will
> > > > > > > > > > > stay in libc —
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The architecture is wrong to host any bluetooth profile
> in
> > > > libc.
> > > > > > > > > >
> > > > > > > > > > in flat build mode this gives a significant performance
> > > > > > > > > > > boost to the overall stack, which is the primary
> > deployment
> > > > > model
> > > > > > > for
> > > > > > > > > > most
> > > > > > > > > > > NuttX devices.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > Performance should remain the same whether the base
> profile
> > > is
> > > > > > hosted
> > > > > > > > in
> > > > > > > > > > libc or apps,
> > > > > > > > > > could you point out any technical reason which impacts
> the
> > > > > > > performance
> > > > > > > > in
> > > > > > > > > > the flat mode?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > A few additional data points regarding our timeline:
> our
> > > > > product
> > > > > > is
> > > > > > > > > > > scheduled for release in December, and Bluetooth SIG
> > > > > > certification
> > > > > > > is
> > > > > > > > > > > already in progress — we expect to receive it around
> > > > November.
> > > > > If
> > > > > > > the
> > > > > > > > > > > baseline were to switch to your team's stack with its
> > > > different
> > > > > > > > > > > architecture, that certification cycle would need to be
> > > > > repeated,
> > > > > > > > which
> > > > > > > > > > is
> > > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > > >
> > > > > > > > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五
> > > > 15:08写道：
> > > > > > > > > > >
> > > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > > magicdcps@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regarding your point about the NimBLE port using
> the
> > > > POSIX
> > > > > > API
> > > > > > > —
> > > > > > > > yes,
> > > > > > > > > > > it
> > > > > > > > > > > > > uses POSIX, but there are real issues with the
> > current
> > > > > > > > implementation
> > > > > > > > > > > > that
> > > > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical
> > > > section
> > > > > > > > > > > > >
> > > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > > >
> > > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > > >
> > > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > > {
> > > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is a mutex, not a critical section. It does
> not
> > > > > disable
> > > > > > > > > > interrupts
> > > > > > > > > > > > or
> > > > > > > > > > > > > preemption — an ISR can still fire and corrupt data
> > > that
> > > > > the
> > > > > > > > > > "critical
> > > > > > > > > > > > > section" was supposed to protect. On top of that,
> > > using a
> > > > > > mutex
> > > > > > > > opens
> > > > > > > > > > > the
> > > > > > > > > > > > > door to ABBA deadlocks when combined with any other
> > > lock
> > > > > held
> > > > > > > > inside
> > > > > > > > > > > the
> > > > > > > > > > > > > critical region:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> > > > > > lock(mutex
> > > > > > > > M) ←
> > > > > > > > > > > > blocked
> > > > > > > > > > > > > by B
> > > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > > lock(s_mutex) ←
> > > > > > > > blocked by
> > > > > > > > > > A
> > > > > > > > > > > > >
> > > > > > > > > > > > > Compare this with the FreeRTOS port, which
> correctly
> > > uses
> > > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e.,
> > > > actually
> > > > > > > > disabling
> > > > > > > > > > > > > scheduling/preemption). The current NuttX port
> simply
> > > > does
> > > > > > not
> > > > > > > > meet
> > > > > > > > > > the
> > > > > > > > > > > > > semantic contract that the NimBLE stack expects
> from
> > > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > > 2. Time subsystem uses clock_gettime instead of
> > kernel
> > > > tick
> > > > > > > APIs
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > > >
> > > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > > ...),
> > > > > > > > > > > > which
> > > > > > > > > > > > > involves a syscall and floating-point arithmetic on
> > > every
> > > > > > call.
> > > > > > > > In a
> > > > > > > > > > > BLE
> > > > > > > > > > > > > stack where timestamps and timing are on the hot
> > path,
> > > > this
> > > > > > > adds
> > > > > > > > > > > > measurable
> > > > > > > > > > > > > overhead compared to accessing the kernel tick
> > counter
> > > > > > > directly.
> > > > > > > > > > > > > 3. Others are already using the kernel approach —
> and
> > > for
> > > > > > good
> > > > > > > > reason
> > > > > > > > > > > > >
> > > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack
> (zblue)
> > > for
> > > > > > > > > > openvela/NuttX
> > > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > > > > > > performance-critical
> > > > > > > > > > > > > paths:
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > >
> > > > > > > > > > > > > This isn't an academic exercise — it's a production
> > > > choice.
> > > > > > > They
> > > > > > > > > > > > recognized
> > > > > > > > > > > > > that a BLE stack needs tight integration with the
> OS
> > > > timer
> > > > > > > > subsystem,
> > > > > > > > > > > > > direct access to critical section primitives, and
> > > > efficient
> > > > > > > event
> > > > > > > > > > > > delivery,
> > > > > > > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > > > > > > My question
> > > > > > > > > > > > >
> > > > > > > > > > > > > If other organizations are already using a more
> > > > performant,
> > > > > > > > > > > > architecturally
> > > > > > > > > > > > > correct kernel-level integration for their BLE
> stacks
> > > on
> > > > > > NuttX,
> > > > > > > > why
> > > > > > > > > > > > should
> > > > > > > > > > > > > we be told that we must use the slower, less
> correct
> > > > POSIX
> > > > > > > path?
> > > > > > > > > > > NuttX's
> > > > > > > > > > > > > POSIX compliance is valuable, but it shouldn't come
> > at
> > > > the
> > > > > > cost
> > > > > > > > of
> > > > > > > > > > > > shipping
> > > > > > > > > > > > > a BLE stack with a broken critical section
> primitive.
> > > > There
> > > > > > > > should be
> > > > > > > > > > > > room
> > > > > > > > > > > > > for both approaches, and the decision should be
> > driven
> > > by
> > > > > > > > technical
> > > > > > > > > > > > merit,
> > > > > > > > > > > > > not by treating POSIX as the only acceptable
> answer.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > I don't object to moving the key bluetooth stack to
> > > kernel
> > > > > > space
> > > > > > > > like
> > > > > > > > > > how
> > > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is far to
> > > move
> > > > > > > entirely
> > > > > > > > > > > > into kernel space.
> > > > > > > > > > > > If I low my quality bar, I have requested my teammate
> > to
> > > > > > upstream
> > > > > > > > our
> > > > > > > > > > > > implementation:
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > > since much work needs to be done before it can
> achieve
> > > the
> > > > > > > quality
> > > > > > > > > > > > upstream.
> > > > > > > > > > > > BTW, many zephyr class BT features are developed by
> my
> > > team
> > > > > and
> > > > > > > > > > upstream
> > > > > > > > > > > to
> > > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > > If considering the quality, our version is much
> better
> > > > since:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at
> > > > 2026.06
> > > > > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alan,
Thank you for the detailed analysis.
I understand your concern. The current code structure is indeed still very
close to Zephyr's Bluetooth stack, and the compatibility layer is currently
quite thin. However, from the long-term technical direction, our intention
is
not to keep doing long-term synchronization with Zephyr. Instead, we plan
to
quickly feed back the related issues and improvements to the NuttX
community
during the integration and evolution process.
Regarding the naming concern, I think it is reasonable to call it zblue
temporarily, since the current implementation is still largely based on
Zephyr's Bluetooth stack. If the stack evolves later with a new code
structure
and clearer NuttX-specific architecture, we can further evaluate whether a
different name would be more appropriate at that time.
Does that sound reasonable to you?
BR,
Alan C. Assis <ac...@gmail.com> 于2026年10月22日周四 03:41写道：
> Hi Anchao,
>
> I used Claude to help compare the code and here are the reasons to call it
> zblue instead of libs/bt:
>
> Almost all of this PR is Zephyr's Bluetooth stack
> ("zblue"), reformatted to NuttX style. The part that doesn't come from
> Zephyr is
> a thin compatibility layer that makes the Zephyr kernel calls work on
> NuttX.
>
> I pulled all 539 new files (400,450 lines) and compared them against
> several
> Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it matches
> better
> than Zephyr's current main branch. So the PR looks like a snapshot of zblue
> from the last few weeks.
>
> Results
>
> Function by function (7,716 functions):
>
> Class: Identical
> Functions: 5,411 (70%)
> Lines: 140,189
> Meaning: Exactly the same code as Zephyr. Only indentation and braces
> differ.
> ────────────────────────────────────────
> Class: Renames only
> Functions: 1,515 (20%)
> Lines: 60,863
> Meaning: The only changes are API renames that recur across the whole PR:
> __ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1), sys_slist_*→list_*,
> k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read
> ────────────────────────────────────────
> Class: Modified
> Functions: 584 (8%)
> Lines: 33,693
> Meaning: Clearly the Zephyr function, plus some edits specific to that
> function
> ────────────────────────────────────────
> Class: Not from Zephyr
> Functions: 206 (3%)
> Lines: 2,734
> Meaning: NuttX glue code
>
> Whole files, including headers:
> - On average, 96.9% of each file's code also appears in its Zephyr
> counterpart.
> - 434 of the 539 files are ≥90% the same as Zephyr; together they hold
> 375k of
> the 400k lines.
> - 75% of the comment text, including the Doxygen docs, is word-for-word
> Zephyr.
>
> What's actually new:
> - The net/bt/compat/ shim layer (kernel/timeout.c, queue.c, mem_slab.c,
> fs.c,
> sections/defines.c, hci_driver.c), which provides k_work, k_queue and
> similar
> Zephyr calls on top of NuttX.
> - Part of mm/net_buf.
> - bt_nus_auto_start_bt.c, which has been heavily extended.
> - hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig.
>
>
> So, only 3% of the code is new (this includes the code in sim:bt that must
> be new).
>
> So, reusing the zblue from Zephyr and calling it something else isn't
> right; it's like the zbus that Jorge brought from Zephyr, where calling it
> NXBus doesn't seem appropriate.
>
> Besides that, as I said before using ZBlue as our official BT Stack will
> significantly increase the shared code between NuttX and Zephyr, which
> could be dangerous.
>
> As I said, I not against adding ZBlue to NuttX, but at least make it clear
> that it is ZBlue and should be an alternative stack (like NimBLE) not the
> official NuttX BLE Stack.
>
> BR,
>
> Alan
>
> On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com> wrote:
>
> > Hi Alan,
> >
> > Thanks for the comments and suggestions.
> >
> > For the first stage, I would prefer to keep the Bluetooth host stack
> > supported only in FLAT mode. Supporting Protected and Kernel modes
> requires
> > a much deeper rework of the stack and its interfaces, especially around
> the
> > boundary between kernel space and user space. I do not think it is a good
> > idea to introduce such large architectural changes in this first step.
> >
> > Our current plan is to complete Protected/Kernel mode support in a second
> > stage, after the basic stack integration is reviewed and stabilized. This
> > should make the initial review and integration much more manageable.
> >
> > Regarding the library name, I still prefer to use libs/libbt. Although
> the
> > current code is based on Zephyr's zblue, the goal is to maintain it as an
> > independent NuttX Bluetooth host stack going forward, rather than keeping
> > it as a direct Zephyr fork forever. In that sense, I think libbt is a
> > better long-term name.
> >
> > Also, the current NuttX Bluetooth profiles are not implemented in the
> > kernel, and we do not plan to move the native NuttX Bluetooth stack
> > profiles into the kernel either. Once Protected/Kernel mode support is
> > added for this stack in the future, this implementation is expected to
> > replace the previous approach. For this reason, I think keeping the stack
> > under libbt is still more appropriate.
> >
> > About splitting the PR: this PR is already the result of squashing more
> > than one hundred commits. Most of those commits are compatibility-layer
> > adjustments, coding style cleanup, and mechanical changes needed to make
> > the stack build in NuttX. Asking reviewers to review each of those
> commits
> > separately would probably cost everyone more time.
> >
> > Splitting the full Bluetooth stack by profile is also not very practical
> at
> > the moment, because there are no dedicated maintainers for each
> individual
> > Bluetooth profile area in NuttX yet. Therefore, I think the current form
> is
> > probably the most reasonable way to review and integrate the stack as a
> > whole.
> >
> > One more update: I have removed all shell-related code from
> > https://github.com/apache/nuttx/pull/20686. The plan is to move those
> > shell
> > commands to apps later. With this change, the current Bluetooth stack no
> > longer contains any user-space shell code, so I think this is now a
> better
> > point for review.
> >
> > Best regards,
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> >
> > > Hi An Chao,
> > >
> > > Isn't it possible to have a similar implementation that works for FLAT,
> > > Protected and Kernel modes?
> > >
> > > This way the maintenance will be easier. Only small kernel-specific
> parts
> > > will remain there (as Raiden and Xiang proposed).
> > >
> > > Suggestion: instead of naming it libs/libbt/, it would be better to use
> > > libs/zblue to make it clear that it is a zblue port from Zephyr.
> > >
> > > Let's use libs/libbt only for NuttX-specific (native) code.
> > >
> > > And as I said, it is better to easily isolate the code that came from
> > > Zephyr's zblue.
> > >
> > > This way the user could select the Bluetooth stack they want without
> > having
> > > code from the other stack attached to it.
> > >
> > > Also I suggest you to break your PR into smaller PRs; a single PR
> > changing
> > > more than 660K LoC is very massive.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > Thank you for the thoughtful perspective and for engaging in the
> > > > discussion.
> > > >
> > > > On security: we will maintain the Bluetooth stack ourselves and take
> > > > responsibility for tracking and fixing vulnerabilities. I'm also
> > > confident
> > > > that Xiaomi will contribute back on security issues given their
> ongoing
> > > > investment in this codebase. This isn't a blind import — it's code
> that
> > > has
> > > > active, committed maintainers behind it.
> > > >
> > > > Regarding the history with Greg: you're right that we discussed this
> > > years
> > > > ago. But there's an important distinction — that earlier proposal
> > placed
> > > > the stack entirely in userspace. It did nothing to strengthen NuttX's
> > > > kernel-level Bluetooth support. That's precisely why I'm back now,
> > > > providing a kernel implementation this time around, which is what I
> > > > committed to back then. Feel free to search the mailing list
> archives —
> > > the
> > > > NuttX native Bluetooth stack will evolve from this baseline going
> > > forward.
> > > >
> > > > This implementation does not affect existing Bluetooth stacks in any
> > way.
> > > > Users can still choose NimBLE, the current NuttX BLE stack, or any
> > other
> > > > solution. This is an additional option, not a replacement. The goal
> is
> > to
> > > > give NuttX users more choices, not fewer.
> > > >
> > > > One more update: I just spoke with Xiaoxiang and we've reached some
> > > common
> > > > ground. He's no longer opposed to the current stack implementation
> and
> > > > agrees that the focus should be on proper structuring. Here's the
> plan
> > > > going forward:
> > > >
> > > > 1. Unused shell code will be moved out of the stack and into
> apps/,
> > > > running entirely in userspace.
> > > > 2. Bluetooth profiles will be migrated to libs/libbt/, where we'll
> > > > provide two OS API backends: a POSIX API implementation (for
> > > > kernel/protected builds) and a NuttX kernel API implementation
> (for
> > > flat
> > > > mode).
> > > > 3. The L2CAP layer will remain in the NuttX kernel.
> > > >
> > > > This should address the architectural concerns while preserving the
> > > > performance path for flat-mode deployments.
> > > >
> > > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > > >
> > > > > Hi An Chao,
> > > > >
> > > > > Thank you for trying to improve the NuttX Bluetooth support. And
> > thank
> > > > you
> > > > > to bring this discussion here to let more people give their
> opinion.
> > > > >
> > > > > I think most of the concerns raised by Xiang and Raiden (Mateusz)
> are
> > > > > important and need to be addressed.
> > > > >
> > > > > As I said at GitHub PR I think a main concern here is using the
> same
> > > > > Bluetooth stack used on Zephyr, not because it is a bad stack (of
> > > course
> > > > it
> > > > > is not, it was developed by experts on Bluetooth area), but because
> > we
> > > > are
> > > > > adding the same surface area of attack from Zephyr on NuttX.
> > > > >
> > > > > That means any security vulnerability affecting Zephyr BLE stack
> will
> > > > > affect NuttX. It remove the protection that a companies could
> obtain
> > > when
> > > > > using different RTOSs.
> > > > >
> > > > > Also, if my memory still serving me, I think Xiaomi team (you was
> > there
> > > > at
> > > > > that time) already tried to submit their initial port of Zephyr BLE
> > > stack
> > > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > > >
> > > > > His suggestion was to improve our BLE stack, that in fact has the
> > same
> > > > > origin of the Zephyr BLE stack (both came from a BLE stack from
> Intel
> > > > > released as BSD license at that time).
> > > > >
> > > > > I'm not against including the Zephyr BLE stack, but it should be
> > > > > selectable. Ideally the user should select if he/she wants to use
> > > NimBLE,
> > > > > Zephyr or NuttX native BLE stack.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Friday, October 16, 2026, chao an <ma...@gmail.com> wrote:
> > > > >
> > > > > > Hi, Tomek,
> > > > > >
> > > > > > Thanks for the thoughtful input and the FreeBSD references —
> those
> > > are
> > > > > very
> > > > > > relevant to where we're heading.
> > > > > >
> > > > > > Just to set the context: NuttX's current Bluetooth stack only
> > > supports
> > > > > BLE.
> > > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all
> missing.
> > > This
> > > > > is
> > > > > > exactly why we want to bring a more complete Bluetooth stack to
> > > NuttX —
> > > > > to
> > > > > > catch up with what mainstream RTOS communities already offer.
> > > > > >
> > > > > > I actually agree with the FreeBSD/Apple architecture you
> > referenced.
> > > > Our
> > > > > > end-state plan is similar: the L2CAP and HCI layers will live in
> > the
> > > > > > kernel, and a bluetoothd-style daemon will be implemented in
> libc,
> > > > > managing
> > > > > > profiles and higher-level protocols. This gives us a clean
> > > separation —
> > > > > > transport in the kernel, policy and profiles in userspace — much
> > like
> > > > how
> > > > > > FreeBSD's ng_hci / hccontrol split works. The current PR is
> Phase 1
> > > of
> > > > > > getting there incrementally.
> > > > > >
> > > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > > >
> > > > > > > Thank you An Chao for this proposition, work, and discussion
> :-)
> > > > > > >
> > > > > > > For sure it would be nice to have a BT stack with more
> features!
> > > The
> > > > > > > BT has known issue of having different implementations of the
> > stack
> > > > on
> > > > > > > different RTOS / OS / platforms, which is a known issue, and
> > kinda
> > > > > > > mess because there is no common standard / approach /
> > > implementation,
> > > > > > > unfortunately around something that is supposed to be based on
> a
> > > > > > > common standard.
> > > > > > >
> > > > > > > Having common BT stack with other popular RTOS may make
> > portability
> > > > > > > easier and developers move to NuttX in some cases.
> > > > > > >
> > > > > > > I understand that we are talking about this solution?
> > > > > > >
> > > > > > >
> > > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > > connectivity/bluetooth/index.html
> > > > > > >
> > > > > > > In a perfect situation we would want to have modular
> > implementation
> > > > in
> > > > > > > nuttx-apps just like nimble. This is pointed out by Xiang,
> > Raiden,
> > > > and
> > > > > > > Alin already. But I understand some things may be hard to
> > implement
> > > > > > > that way. I will follow the consensus here when ready, I have
> no
> > > > > > > strong opinion here, except any BT stack I touched before was a
> > > mess
> > > > > > > and I hope we can work out at least something decent :-P
> > > > > > >
> > > > > > > A bit offtopic but for kernel build we can take a look at quite
> > old
> > > > > > > Bluetooth implementation on FreeBSD, where radio is provided by
> > > > ng_ubt
> > > > > > > (lower half in out case), then upper half uses standard HCI.
> > Maybe
> > > > > > > something like this is possible in NuttX?
> > > > > > >
> > > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > > 4.
> https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > > 5.
> https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > > >
> > > > > > > Here is a quick overview article on the Bluetooth
> implementation
> > in
> > > > > > > FreeBSD and Apple:
> > > > > > >
> > > > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > > >
> > > > > > > Again it will be very nice to have fully featured BT stack in
> > NuttX
> > > > > > > and I hope we can sort out the best possible porting
> > implementation
> > > > > > > :-)
> > > > > > >
> > > > > > > --
> > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > >
> > > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> > jerpelea@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > thanks Xiao and Raiden for your technical opinions which I
> also
> > > > share
> > > > > > so
> > > > > > > I
> > > > > > > > will not iterate them again.
> > > > > > > >
> > > > > > > > I am against merging this pr in NuttX repo
> > > > > > > > it should be splitted between nuttx and apps-repos and use
> > POSIX
> > > > > > > > implementation as much as possible. We are focused on
> standards
> > > and
> > > > > > > > compatibility.
> > > > > > > >
> > > > > > > > Another concern is the license which does not match our ASF
> one
> > > and
> > > > > > does
> > > > > > > > not include any LICENSE file additions to clarify the
> compiance
> > > > > aspect
> > > > > > > >
> > > > > > > > Best regards
> > > > > > > > Alin J
> > > > > > > >
> > > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > > xiaoxiang781216@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <
> magicdcps@gmail.com
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > So the real reason you've been objecting to my proposal
> is
> > > that
> > > > > > your
> > > > > > > team
> > > > > > > > > > has been working on something similar, correct?
> > > > > > > > > >
> > > > > > > > > > If you can give me a clear timeline for when your
> > > > implementation
> > > > > > > will be
> > > > > > > > > > submitted upstream, I'm happy to withdraw my PR and let
> > your
> > > > code
> > > > > > > serve
> > > > > > > > > as
> > > > > > > > > > the baseline. I'm not here to fight over ownership of the
> > > > > Bluetooth
> > > > > > > > > stack.
> > > > > > > > > > My only motivation is that NuttX's lack of a capable
> > > Bluetooth
> > > > > > stack
> > > > > > > is
> > > > > > > > > > driving every developer toward Zephyr — and as a PMC
> > member,
> > > I
> > > > > > think
> > > > > > > you
> > > > > > > > > > should be asking yourselves why this gap has remained
> > > unfilled
> > > > > for
> > > > > > so
> > > > > > > > > long.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > I object to landing the whole bluetooth stack into kernel
> > space
> > > > > > > directly
> > > > > > > > > either yours and ours .
> > > > > > > > > This is the same feeling from raiden00pl too, let's see
> other
> > > > > > people's
> > > > > > > > > opinions here.
> > > > > > > > > But it's fine for me to host the whole code in
> nuttx-apps.git
> > > and
> > > > > > > refactor
> > > > > > > > > components to kernel
> > > > > > > > > space step by step.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > As for the current PR, I'll remove the shell components
> > from
> > > > the
> > > > > > > stack
> > > > > > > > > and
> > > > > > > > > > move them into apps/ where they belong. The base profiles
> > > > (A2DP,
> > > > > > BLE)
> > > > > > > > > will
> > > > > > > > > > stay in libc —
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The architecture is wrong to host any bluetooth profile in
> > > libc.
> > > > > > > > >
> > > > > > > > > in flat build mode this gives a significant performance
> > > > > > > > > > boost to the overall stack, which is the primary
> deployment
> > > > model
> > > > > > for
> > > > > > > > > most
> > > > > > > > > > NuttX devices.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > Performance should remain the same whether the base profile
> > is
> > > > > hosted
> > > > > > > in
> > > > > > > > > libc or apps,
> > > > > > > > > could you point out any technical reason which impacts the
> > > > > > performance
> > > > > > > in
> > > > > > > > > the flat mode?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > A few additional data points regarding our timeline: our
> > > > product
> > > > > is
> > > > > > > > > > scheduled for release in December, and Bluetooth SIG
> > > > > certification
> > > > > > is
> > > > > > > > > > already in progress — we expect to receive it around
> > > November.
> > > > If
> > > > > > the
> > > > > > > > > > baseline were to switch to your team's stack with its
> > > different
> > > > > > > > > > architecture, that certification cycle would need to be
> > > > repeated,
> > > > > > > which
> > > > > > > > > is
> > > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > > >
> > > > > > > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五
> > > 15:08写道：
> > > > > > > > > >
> > > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > > magicdcps@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > > >
> > > > > > > > > > > > Regarding your point about the NimBLE port using the
> > > POSIX
> > > > > API
> > > > > > —
> > > > > > > yes,
> > > > > > > > > > it
> > > > > > > > > > > > uses POSIX, but there are real issues with the
> current
> > > > > > > implementation
> > > > > > > > > > > that
> > > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical
> > > section
> > > > > > > > > > > >
> > > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > > >
> > > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > > >
> > > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > > {
> > > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > > return 0;
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > This is a mutex, not a critical section. It does not
> > > > disable
> > > > > > > > > interrupts
> > > > > > > > > > > or
> > > > > > > > > > > > preemption — an ISR can still fire and corrupt data
> > that
> > > > the
> > > > > > > > > "critical
> > > > > > > > > > > > section" was supposed to protect. On top of that,
> > using a
> > > > > mutex
> > > > > > > opens
> > > > > > > > > > the
> > > > > > > > > > > > door to ABBA deadlocks when combined with any other
> > lock
> > > > held
> > > > > > > inside
> > > > > > > > > > the
> > > > > > > > > > > > critical region:
> > > > > > > > > > > >
> > > > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> > > > > lock(mutex
> > > > > > > M) ←
> > > > > > > > > > > blocked
> > > > > > > > > > > > by B
> > > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> > lock(s_mutex) ←
> > > > > > > blocked by
> > > > > > > > > A
> > > > > > > > > > > >
> > > > > > > > > > > > Compare this with the FreeRTOS port, which correctly
> > uses
> > > > > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e.,
> > > actually
> > > > > > > disabling
> > > > > > > > > > > > scheduling/preemption). The current NuttX port simply
> > > does
> > > > > not
> > > > > > > meet
> > > > > > > > > the
> > > > > > > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > > 2. Time subsystem uses clock_gettime instead of
> kernel
> > > tick
> > > > > > APIs
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > > >
> > > > > > > > > > > > ble_npl_time_get() is backed by
> > > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > > ...),
> > > > > > > > > > > which
> > > > > > > > > > > > involves a syscall and floating-point arithmetic on
> > every
> > > > > call.
> > > > > > > In a
> > > > > > > > > > BLE
> > > > > > > > > > > > stack where timestamps and timing are on the hot
> path,
> > > this
> > > > > > adds
> > > > > > > > > > > measurable
> > > > > > > > > > > > overhead compared to accessing the kernel tick
> counter
> > > > > > directly.
> > > > > > > > > > > > 3. Others are already using the kernel approach — and
> > for
> > > > > good
> > > > > > > reason
> > > > > > > > > > > >
> > > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue)
> > for
> > > > > > > > > openvela/NuttX
> > > > > > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > > > > > performance-critical
> > > > > > > > > > > > paths:
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > >
> > > > > > > > > > > > This isn't an academic exercise — it's a production
> > > choice.
> > > > > > They
> > > > > > > > > > > recognized
> > > > > > > > > > > > that a BLE stack needs tight integration with the OS
> > > timer
> > > > > > > subsystem,
> > > > > > > > > > > > direct access to critical section primitives, and
> > > efficient
> > > > > > event
> > > > > > > > > > > delivery,
> > > > > > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > > > > > My question
> > > > > > > > > > > >
> > > > > > > > > > > > If other organizations are already using a more
> > > performant,
> > > > > > > > > > > architecturally
> > > > > > > > > > > > correct kernel-level integration for their BLE stacks
> > on
> > > > > NuttX,
> > > > > > > why
> > > > > > > > > > > should
> > > > > > > > > > > > we be told that we must use the slower, less correct
> > > POSIX
> > > > > > path?
> > > > > > > > > > NuttX's
> > > > > > > > > > > > POSIX compliance is valuable, but it shouldn't come
> at
> > > the
> > > > > cost
> > > > > > > of
> > > > > > > > > > > shipping
> > > > > > > > > > > > a BLE stack with a broken critical section primitive.
> > > There
> > > > > > > should be
> > > > > > > > > > > room
> > > > > > > > > > > > for both approaches, and the decision should be
> driven
> > by
> > > > > > > technical
> > > > > > > > > > > merit,
> > > > > > > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > I don't object to moving the key bluetooth stack to
> > kernel
> > > > > space
> > > > > > > like
> > > > > > > > > how
> > > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is far to
> > move
> > > > > > entirely
> > > > > > > > > > > into kernel space.
> > > > > > > > > > > If I low my quality bar, I have requested my teammate
> to
> > > > > upstream
> > > > > > > our
> > > > > > > > > > > implementation:
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > > since much work needs to be done before it can achieve
> > the
> > > > > > quality
> > > > > > > > > > > upstream.
> > > > > > > > > > > BTW, many zephyr class BT features are developed by my
> > team
> > > > and
> > > > > > > > > upstream
> > > > > > > > > > to
> > > > > > > > > > > Zeprhy community.
> > > > > > > > > > > If considering the quality, our version is much better
> > > since:
> > > > > > > > > > >
> > > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at
> > > 2026.06
> > > > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Anchao,
I used Claude to help compare the code and here are the reasons to call it
zblue instead of libs/bt:
Almost all of this PR is Zephyr's Bluetooth stack
("zblue"), reformatted to NuttX style. The part that doesn't come from
Zephyr is
a thin compatibility layer that makes the Zephyr kernel calls work on NuttX.
I pulled all 539 new files (400,450 lines) and compared them against several
Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it matches
better
than Zephyr's current main branch. So the PR looks like a snapshot of zblue
from the last few weeks.
Results
Function by function (7,716 functions):
Class: Identical
Functions: 5,411 (70%)
Lines: 140,189
Meaning: Exactly the same code as Zephyr. Only indentation and braces
differ.
────────────────────────────────────────
Class: Renames only
Functions: 1,515 (20%)
Lines: 60,863
Meaning: The only changes are API renames that recur across the whole PR:
__ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1), sys_slist_*→list_*,
k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read
────────────────────────────────────────
Class: Modified
Functions: 584 (8%)
Lines: 33,693
Meaning: Clearly the Zephyr function, plus some edits specific to that
function
────────────────────────────────────────
Class: Not from Zephyr
Functions: 206 (3%)
Lines: 2,734
Meaning: NuttX glue code
Whole files, including headers:
- On average, 96.9% of each file's code also appears in its Zephyr
counterpart.
- 434 of the 539 files are ≥90% the same as Zephyr; together they hold
375k of
the 400k lines.
- 75% of the comment text, including the Doxygen docs, is word-for-word
Zephyr.
What's actually new:
- The net/bt/compat/ shim layer (kernel/timeout.c, queue.c, mem_slab.c,
fs.c,
sections/defines.c, hci_driver.c), which provides k_work, k_queue and
similar
Zephyr calls on top of NuttX.
- Part of mm/net_buf.
- bt_nus_auto_start_bt.c, which has been heavily extended.
- hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig.
So, only 3% of the code is new (this includes the code in sim:bt that must
be new).
So, reusing the zblue from Zephyr and calling it something else isn't
right; it's like the zbus that Jorge brought from Zephyr, where calling it
NXBus doesn't seem appropriate.
Besides that, as I said before using ZBlue as our official BT Stack will
significantly increase the shared code between NuttX and Zephyr, which
could be dangerous.
As I said, I not against adding ZBlue to NuttX, but at least make it clear
that it is ZBlue and should be an alternative stack (like NimBLE) not the
official NuttX BLE Stack.
BR,
Alan
On Mon, Oct 19, 2026 at 12:34 AM chao an <ma...@gmail.com> wrote:
> Hi Alan,
>
> Thanks for the comments and suggestions.
>
> For the first stage, I would prefer to keep the Bluetooth host stack
> supported only in FLAT mode. Supporting Protected and Kernel modes requires
> a much deeper rework of the stack and its interfaces, especially around the
> boundary between kernel space and user space. I do not think it is a good
> idea to introduce such large architectural changes in this first step.
>
> Our current plan is to complete Protected/Kernel mode support in a second
> stage, after the basic stack integration is reviewed and stabilized. This
> should make the initial review and integration much more manageable.
>
> Regarding the library name, I still prefer to use libs/libbt. Although the
> current code is based on Zephyr's zblue, the goal is to maintain it as an
> independent NuttX Bluetooth host stack going forward, rather than keeping
> it as a direct Zephyr fork forever. In that sense, I think libbt is a
> better long-term name.
>
> Also, the current NuttX Bluetooth profiles are not implemented in the
> kernel, and we do not plan to move the native NuttX Bluetooth stack
> profiles into the kernel either. Once Protected/Kernel mode support is
> added for this stack in the future, this implementation is expected to
> replace the previous approach. For this reason, I think keeping the stack
> under libbt is still more appropriate.
>
> About splitting the PR: this PR is already the result of squashing more
> than one hundred commits. Most of those commits are compatibility-layer
> adjustments, coding style cleanup, and mechanical changes needed to make
> the stack build in NuttX. Asking reviewers to review each of those commits
> separately would probably cost everyone more time.
>
> Splitting the full Bluetooth stack by profile is also not very practical at
> the moment, because there are no dedicated maintainers for each individual
> Bluetooth profile area in NuttX yet. Therefore, I think the current form is
> probably the most reasonable way to review and integrate the stack as a
> whole.
>
> One more update: I have removed all shell-related code from
> https://github.com/apache/nuttx/pull/20686. The plan is to move those
> shell
> commands to apps later. With this change, the current Bluetooth stack no
> longer contains any user-space shell code, so I think this is now a better
> point for review.
>
> Best regards,
>
> Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
>
> > Hi An Chao,
> >
> > Isn't it possible to have a similar implementation that works for FLAT,
> > Protected and Kernel modes?
> >
> > This way the maintenance will be easier. Only small kernel-specific parts
> > will remain there (as Raiden and Xiang proposed).
> >
> > Suggestion: instead of naming it libs/libbt/, it would be better to use
> > libs/zblue to make it clear that it is a zblue port from Zephyr.
> >
> > Let's use libs/libbt only for NuttX-specific (native) code.
> >
> > And as I said, it is better to easily isolate the code that came from
> > Zephyr's zblue.
> >
> > This way the user could select the Bluetooth stack they want without
> having
> > code from the other stack attached to it.
> >
> > Also I suggest you to break your PR into smaller PRs; a single PR
> changing
> > more than 660K LoC is very massive.
> >
> > BR,
> >
> > Alan
> >
> > On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi Alan,
> > >
> > > Thank you for the thoughtful perspective and for engaging in the
> > > discussion.
> > >
> > > On security: we will maintain the Bluetooth stack ourselves and take
> > > responsibility for tracking and fixing vulnerabilities. I'm also
> > confident
> > > that Xiaomi will contribute back on security issues given their ongoing
> > > investment in this codebase. This isn't a blind import — it's code that
> > has
> > > active, committed maintainers behind it.
> > >
> > > Regarding the history with Greg: you're right that we discussed this
> > years
> > > ago. But there's an important distinction — that earlier proposal
> placed
> > > the stack entirely in userspace. It did nothing to strengthen NuttX's
> > > kernel-level Bluetooth support. That's precisely why I'm back now,
> > > providing a kernel implementation this time around, which is what I
> > > committed to back then. Feel free to search the mailing list archives —
> > the
> > > NuttX native Bluetooth stack will evolve from this baseline going
> > forward.
> > >
> > > This implementation does not affect existing Bluetooth stacks in any
> way.
> > > Users can still choose NimBLE, the current NuttX BLE stack, or any
> other
> > > solution. This is an additional option, not a replacement. The goal is
> to
> > > give NuttX users more choices, not fewer.
> > >
> > > One more update: I just spoke with Xiaoxiang and we've reached some
> > common
> > > ground. He's no longer opposed to the current stack implementation and
> > > agrees that the focus should be on proper structuring. Here's the plan
> > > going forward:
> > >
> > > 1. Unused shell code will be moved out of the stack and into apps/,
> > > running entirely in userspace.
> > > 2. Bluetooth profiles will be migrated to libs/libbt/, where we'll
> > > provide two OS API backends: a POSIX API implementation (for
> > > kernel/protected builds) and a NuttX kernel API implementation (for
> > flat
> > > mode).
> > > 3. The L2CAP layer will remain in the NuttX kernel.
> > >
> > > This should address the architectural concerns while preserving the
> > > performance path for flat-mode deployments.
> > >
> > > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> > >
> > > > Hi An Chao,
> > > >
> > > > Thank you for trying to improve the NuttX Bluetooth support. And
> thank
> > > you
> > > > to bring this discussion here to let more people give their opinion.
> > > >
> > > > I think most of the concerns raised by Xiang and Raiden (Mateusz) are
> > > > important and need to be addressed.
> > > >
> > > > As I said at GitHub PR I think a main concern here is using the same
> > > > Bluetooth stack used on Zephyr, not because it is a bad stack (of
> > course
> > > it
> > > > is not, it was developed by experts on Bluetooth area), but because
> we
> > > are
> > > > adding the same surface area of attack from Zephyr on NuttX.
> > > >
> > > > That means any security vulnerability affecting Zephyr BLE stack will
> > > > affect NuttX. It remove the protection that a companies could obtain
> > when
> > > > using different RTOSs.
> > > >
> > > > Also, if my memory still serving me, I think Xiaomi team (you was
> there
> > > at
> > > > that time) already tried to submit their initial port of Zephyr BLE
> > stack
> > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > >
> > > > His suggestion was to improve our BLE stack, that in fact has the
> same
> > > > origin of the Zephyr BLE stack (both came from a BLE stack from Intel
> > > > released as BSD license at that time).
> > > >
> > > > I'm not against including the Zephyr BLE stack, but it should be
> > > > selectable. Ideally the user should select if he/she wants to use
> > NimBLE,
> > > > Zephyr or NuttX native BLE stack.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Friday, October 16, 2026, chao an <ma...@gmail.com> wrote:
> > > >
> > > > > Hi, Tomek,
> > > > >
> > > > > Thanks for the thoughtful input and the FreeBSD references — those
> > are
> > > > very
> > > > > relevant to where we're heading.
> > > > >
> > > > > Just to set the context: NuttX's current Bluetooth stack only
> > supports
> > > > BLE.
> > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing.
> > This
> > > > is
> > > > > exactly why we want to bring a more complete Bluetooth stack to
> > NuttX —
> > > > to
> > > > > catch up with what mainstream RTOS communities already offer.
> > > > >
> > > > > I actually agree with the FreeBSD/Apple architecture you
> referenced.
> > > Our
> > > > > end-state plan is similar: the L2CAP and HCI layers will live in
> the
> > > > > kernel, and a bluetoothd-style daemon will be implemented in libc,
> > > > managing
> > > > > profiles and higher-level protocols. This gives us a clean
> > separation —
> > > > > transport in the kernel, policy and profiles in userspace — much
> like
> > > how
> > > > > FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1
> > of
> > > > > getting there incrementally.
> > > > >
> > > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > > >
> > > > > > Thank you An Chao for this proposition, work, and discussion :-)
> > > > > >
> > > > > > For sure it would be nice to have a BT stack with more features!
> > The
> > > > > > BT has known issue of having different implementations of the
> stack
> > > on
> > > > > > different RTOS / OS / platforms, which is a known issue, and
> kinda
> > > > > > mess because there is no common standard / approach /
> > implementation,
> > > > > > unfortunately around something that is supposed to be based on a
> > > > > > common standard.
> > > > > >
> > > > > > Having common BT stack with other popular RTOS may make
> portability
> > > > > > easier and developers move to NuttX in some cases.
> > > > > >
> > > > > > I understand that we are talking about this solution?
> > > > > >
> > > > > >
> > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > connectivity/bluetooth/index.html
> > > > > >
> > > > > > In a perfect situation we would want to have modular
> implementation
> > > in
> > > > > > nuttx-apps just like nimble. This is pointed out by Xiang,
> Raiden,
> > > and
> > > > > > Alin already. But I understand some things may be hard to
> implement
> > > > > > that way. I will follow the consensus here when ready, I have no
> > > > > > strong opinion here, except any BT stack I touched before was a
> > mess
> > > > > > and I hope we can work out at least something decent :-P
> > > > > >
> > > > > > A bit offtopic but for kernel build we can take a look at quite
> old
> > > > > > Bluetooth implementation on FreeBSD, where radio is provided by
> > > ng_ubt
> > > > > > (lower half in out case), then upper half uses standard HCI.
> Maybe
> > > > > > something like this is possible in NuttX?
> > > > > >
> > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > >
> > > > > > Here is a quick overview article on the Bluetooth implementation
> in
> > > > > > FreeBSD and Apple:
> > > > > >
> > > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > >
> > > > > > Again it will be very nice to have fully featured BT stack in
> NuttX
> > > > > > and I hope we can sort out the best possible porting
> implementation
> > > > > > :-)
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> jerpelea@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > thanks Xiao and Raiden for your technical opinions which I also
> > > share
> > > > > so
> > > > > > I
> > > > > > > will not iterate them again.
> > > > > > >
> > > > > > > I am against merging this pr in NuttX repo
> > > > > > > it should be splitted between nuttx and apps-repos and use
> POSIX
> > > > > > > implementation as much as possible. We are focused on standards
> > and
> > > > > > > compatibility.
> > > > > > >
> > > > > > > Another concern is the license which does not match our ASF one
> > and
> > > > > does
> > > > > > > not include any LICENSE file additions to clarify the compiance
> > > > aspect
> > > > > > >
> > > > > > > Best regards
> > > > > > > Alin J
> > > > > > >
> > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > xiaoxiang781216@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <magicdcps@gmail.com
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > So the real reason you've been objecting to my proposal is
> > that
> > > > > your
> > > > > > team
> > > > > > > > > has been working on something similar, correct?
> > > > > > > > >
> > > > > > > > > If you can give me a clear timeline for when your
> > > implementation
> > > > > > will be
> > > > > > > > > submitted upstream, I'm happy to withdraw my PR and let
> your
> > > code
> > > > > > serve
> > > > > > > > as
> > > > > > > > > the baseline. I'm not here to fight over ownership of the
> > > > Bluetooth
> > > > > > > > stack.
> > > > > > > > > My only motivation is that NuttX's lack of a capable
> > Bluetooth
> > > > > stack
> > > > > > is
> > > > > > > > > driving every developer toward Zephyr — and as a PMC
> member,
> > I
> > > > > think
> > > > > > you
> > > > > > > > > should be asking yourselves why this gap has remained
> > unfilled
> > > > for
> > > > > so
> > > > > > > > long.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > I object to landing the whole bluetooth stack into kernel
> space
> > > > > > directly
> > > > > > > > either yours and ours .
> > > > > > > > This is the same feeling from raiden00pl too, let's see other
> > > > > people's
> > > > > > > > opinions here.
> > > > > > > > But it's fine for me to host the whole code in nuttx-apps.git
> > and
> > > > > > refactor
> > > > > > > > components to kernel
> > > > > > > > space step by step.
> > > > > > > >
> > > > > > > >
> > > > > > > > > As for the current PR, I'll remove the shell components
> from
> > > the
> > > > > > stack
> > > > > > > > and
> > > > > > > > > move them into apps/ where they belong. The base profiles
> > > (A2DP,
> > > > > BLE)
> > > > > > > > will
> > > > > > > > > stay in libc —
> > > > > > > >
> > > > > > > >
> > > > > > > > The architecture is wrong to host any bluetooth profile in
> > libc.
> > > > > > > >
> > > > > > > > in flat build mode this gives a significant performance
> > > > > > > > > boost to the overall stack, which is the primary deployment
> > > model
> > > > > for
> > > > > > > > most
> > > > > > > > > NuttX devices.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > Performance should remain the same whether the base profile
> is
> > > > hosted
> > > > > > in
> > > > > > > > libc or apps,
> > > > > > > > could you point out any technical reason which impacts the
> > > > > performance
> > > > > > in
> > > > > > > > the flat mode?
> > > > > > > >
> > > > > > > >
> > > > > > > > > A few additional data points regarding our timeline: our
> > > product
> > > > is
> > > > > > > > > scheduled for release in December, and Bluetooth SIG
> > > > certification
> > > > > is
> > > > > > > > > already in progress — we expect to receive it around
> > November.
> > > If
> > > > > the
> > > > > > > > > baseline were to switch to your team's stack with its
> > different
> > > > > > > > > architecture, that certification cycle would need to be
> > > repeated,
> > > > > > which
> > > > > > > > is
> > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > >
> > > > > > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五
> > 15:08写道：
> > > > > > > > >
> > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > magicdcps@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > >
> > > > > > > > > > > Regarding your point about the NimBLE port using the
> > POSIX
> > > > API
> > > > > —
> > > > > > yes,
> > > > > > > > > it
> > > > > > > > > > > uses POSIX, but there are real issues with the current
> > > > > > implementation
> > > > > > > > > > that
> > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical
> > section
> > > > > > > > > > >
> > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > >
> > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > >
> > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > {
> > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > return 0;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > This is a mutex, not a critical section. It does not
> > > disable
> > > > > > > > interrupts
> > > > > > > > > > or
> > > > > > > > > > > preemption — an ISR can still fire and corrupt data
> that
> > > the
> > > > > > > > "critical
> > > > > > > > > > > section" was supposed to protect. On top of that,
> using a
> > > > mutex
> > > > > > opens
> > > > > > > > > the
> > > > > > > > > > > door to ABBA deadlocks when combined with any other
> lock
> > > held
> > > > > > inside
> > > > > > > > > the
> > > > > > > > > > > critical region:
> > > > > > > > > > >
> > > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> > > > lock(mutex
> > > > > > M) ←
> > > > > > > > > > blocked
> > > > > > > > > > > by B
> > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> lock(s_mutex) ←
> > > > > > blocked by
> > > > > > > > A
> > > > > > > > > > >
> > > > > > > > > > > Compare this with the FreeRTOS port, which correctly
> uses
> > > > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e.,
> > actually
> > > > > > disabling
> > > > > > > > > > > scheduling/preemption). The current NuttX port simply
> > does
> > > > not
> > > > > > meet
> > > > > > > > the
> > > > > > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > 2. Time subsystem uses clock_gettime instead of kernel
> > tick
> > > > > APIs
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > >
> > > > > > > > > > > ble_npl_time_get() is backed by
> > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > ...),
> > > > > > > > > > which
> > > > > > > > > > > involves a syscall and floating-point arithmetic on
> every
> > > > call.
> > > > > > In a
> > > > > > > > > BLE
> > > > > > > > > > > stack where timestamps and timing are on the hot path,
> > this
> > > > > adds
> > > > > > > > > > measurable
> > > > > > > > > > > overhead compared to accessing the kernel tick counter
> > > > > directly.
> > > > > > > > > > > 3. Others are already using the kernel approach — and
> for
> > > > good
> > > > > > reason
> > > > > > > > > > >
> > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue)
> for
> > > > > > > > openvela/NuttX
> > > > > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > > > > performance-critical
> > > > > > > > > > > paths:
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > >
> > > > > > > > > > > This isn't an academic exercise — it's a production
> > choice.
> > > > > They
> > > > > > > > > > recognized
> > > > > > > > > > > that a BLE stack needs tight integration with the OS
> > timer
> > > > > > subsystem,
> > > > > > > > > > > direct access to critical section primitives, and
> > efficient
> > > > > event
> > > > > > > > > > delivery,
> > > > > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > > > > My question
> > > > > > > > > > >
> > > > > > > > > > > If other organizations are already using a more
> > performant,
> > > > > > > > > > architecturally
> > > > > > > > > > > correct kernel-level integration for their BLE stacks
> on
> > > > NuttX,
> > > > > > why
> > > > > > > > > > should
> > > > > > > > > > > we be told that we must use the slower, less correct
> > POSIX
> > > > > path?
> > > > > > > > > NuttX's
> > > > > > > > > > > POSIX compliance is valuable, but it shouldn't come at
> > the
> > > > cost
> > > > > > of
> > > > > > > > > > shipping
> > > > > > > > > > > a BLE stack with a broken critical section primitive.
> > There
> > > > > > should be
> > > > > > > > > > room
> > > > > > > > > > > for both approaches, and the decision should be driven
> by
> > > > > > technical
> > > > > > > > > > merit,
> > > > > > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > I don't object to moving the key bluetooth stack to
> kernel
> > > > space
> > > > > > like
> > > > > > > > how
> > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is far to
> move
> > > > > entirely
> > > > > > > > > > into kernel space.
> > > > > > > > > > If I low my quality bar, I have requested my teammate to
> > > > upstream
> > > > > > our
> > > > > > > > > > implementation:
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > since much work needs to be done before it can achieve
> the
> > > > > quality
> > > > > > > > > > upstream.
> > > > > > > > > > BTW, many zephyr class BT features are developed by my
> team
> > > and
> > > > > > > > upstream
> > > > > > > > > to
> > > > > > > > > > Zeprhy community.
> > > > > > > > > > If considering the quality, our version is much better
> > since:
> > > > > > > > > >
> > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at
> > 2026.06
> > > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alan,
Thanks for the comments and suggestions.
For the first stage, I would prefer to keep the Bluetooth host stack
supported only in FLAT mode. Supporting Protected and Kernel modes requires
a much deeper rework of the stack and its interfaces, especially around the
boundary between kernel space and user space. I do not think it is a good
idea to introduce such large architectural changes in this first step.
Our current plan is to complete Protected/Kernel mode support in a second
stage, after the basic stack integration is reviewed and stabilized. This
should make the initial review and integration much more manageable.
Regarding the library name, I still prefer to use libs/libbt. Although the
current code is based on Zephyr's zblue, the goal is to maintain it as an
independent NuttX Bluetooth host stack going forward, rather than keeping
it as a direct Zephyr fork forever. In that sense, I think libbt is a
better long-term name.
Also, the current NuttX Bluetooth profiles are not implemented in the
kernel, and we do not plan to move the native NuttX Bluetooth stack
profiles into the kernel either. Once Protected/Kernel mode support is
added for this stack in the future, this implementation is expected to
replace the previous approach. For this reason, I think keeping the stack
under libbt is still more appropriate.
About splitting the PR: this PR is already the result of squashing more
than one hundred commits. Most of those commits are compatibility-layer
adjustments, coding style cleanup, and mechanical changes needed to make
the stack build in NuttX. Asking reviewers to review each of those commits
separately would probably cost everyone more time.
Splitting the full Bluetooth stack by profile is also not very practical at
the moment, because there are no dedicated maintainers for each individual
Bluetooth profile area in NuttX yet. Therefore, I think the current form is
probably the most reasonable way to review and integrate the stack as a
whole.
One more update: I have removed all shell-related code from
https://github.com/apache/nuttx/pull/20686. The plan is to move those shell
commands to apps later. With this change, the current Bluetooth stack no
longer contains any user-space shell code, so I think this is now a better
point for review.
Best regards,
Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 21:40写道：
> Hi An Chao,
>
> Isn't it possible to have a similar implementation that works for FLAT,
> Protected and Kernel modes?
>
> This way the maintenance will be easier. Only small kernel-specific parts
> will remain there (as Raiden and Xiang proposed).
>
> Suggestion: instead of naming it libs/libbt/, it would be better to use
> libs/zblue to make it clear that it is a zblue port from Zephyr.
>
> Let's use libs/libbt only for NuttX-specific (native) code.
>
> And as I said, it is better to easily isolate the code that came from
> Zephyr's zblue.
>
> This way the user could select the Bluetooth stack they want without having
> code from the other stack attached to it.
>
> Also I suggest you to break your PR into smaller PRs; a single PR changing
> more than 660K LoC is very massive.
>
> BR,
>
> Alan
>
> On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com> wrote:
>
> > Hi Alan,
> >
> > Thank you for the thoughtful perspective and for engaging in the
> > discussion.
> >
> > On security: we will maintain the Bluetooth stack ourselves and take
> > responsibility for tracking and fixing vulnerabilities. I'm also
> confident
> > that Xiaomi will contribute back on security issues given their ongoing
> > investment in this codebase. This isn't a blind import — it's code that
> has
> > active, committed maintainers behind it.
> >
> > Regarding the history with Greg: you're right that we discussed this
> years
> > ago. But there's an important distinction — that earlier proposal placed
> > the stack entirely in userspace. It did nothing to strengthen NuttX's
> > kernel-level Bluetooth support. That's precisely why I'm back now,
> > providing a kernel implementation this time around, which is what I
> > committed to back then. Feel free to search the mailing list archives —
> the
> > NuttX native Bluetooth stack will evolve from this baseline going
> forward.
> >
> > This implementation does not affect existing Bluetooth stacks in any way.
> > Users can still choose NimBLE, the current NuttX BLE stack, or any other
> > solution. This is an additional option, not a replacement. The goal is to
> > give NuttX users more choices, not fewer.
> >
> > One more update: I just spoke with Xiaoxiang and we've reached some
> common
> > ground. He's no longer opposed to the current stack implementation and
> > agrees that the focus should be on proper structuring. Here's the plan
> > going forward:
> >
> > 1. Unused shell code will be moved out of the stack and into apps/,
> > running entirely in userspace.
> > 2. Bluetooth profiles will be migrated to libs/libbt/, where we'll
> > provide two OS API backends: a POSIX API implementation (for
> > kernel/protected builds) and a NuttX kernel API implementation (for
> flat
> > mode).
> > 3. The L2CAP layer will remain in the NuttX kernel.
> >
> > This should address the architectural concerns while preserving the
> > performance path for flat-mode deployments.
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> >
> > > Hi An Chao,
> > >
> > > Thank you for trying to improve the NuttX Bluetooth support. And thank
> > you
> > > to bring this discussion here to let more people give their opinion.
> > >
> > > I think most of the concerns raised by Xiang and Raiden (Mateusz) are
> > > important and need to be addressed.
> > >
> > > As I said at GitHub PR I think a main concern here is using the same
> > > Bluetooth stack used on Zephyr, not because it is a bad stack (of
> course
> > it
> > > is not, it was developed by experts on Bluetooth area), but because we
> > are
> > > adding the same surface area of attack from Zephyr on NuttX.
> > >
> > > That means any security vulnerability affecting Zephyr BLE stack will
> > > affect NuttX. It remove the protection that a companies could obtain
> when
> > > using different RTOSs.
> > >
> > > Also, if my memory still serving me, I think Xiaomi team (you was there
> > at
> > > that time) already tried to submit their initial port of Zephyr BLE
> stack
> > > to NuttX about 4 or 5 years ago and Greg was against it.
> > >
> > > His suggestion was to improve our BLE stack, that in fact has the same
> > > origin of the Zephyr BLE stack (both came from a BLE stack from Intel
> > > released as BSD license at that time).
> > >
> > > I'm not against including the Zephyr BLE stack, but it should be
> > > selectable. Ideally the user should select if he/she wants to use
> NimBLE,
> > > Zephyr or NuttX native BLE stack.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Friday, October 16, 2026, chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi, Tomek,
> > > >
> > > > Thanks for the thoughtful input and the FreeBSD references — those
> are
> > > very
> > > > relevant to where we're heading.
> > > >
> > > > Just to set the context: NuttX's current Bluetooth stack only
> supports
> > > BLE.
> > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing.
> This
> > > is
> > > > exactly why we want to bring a more complete Bluetooth stack to
> NuttX —
> > > to
> > > > catch up with what mainstream RTOS communities already offer.
> > > >
> > > > I actually agree with the FreeBSD/Apple architecture you referenced.
> > Our
> > > > end-state plan is similar: the L2CAP and HCI layers will live in the
> > > > kernel, and a bluetoothd-style daemon will be implemented in libc,
> > > managing
> > > > profiles and higher-level protocols. This gives us a clean
> separation —
> > > > transport in the kernel, policy and profiles in userspace — much like
> > how
> > > > FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1
> of
> > > > getting there incrementally.
> > > >
> > > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > > >
> > > > > Thank you An Chao for this proposition, work, and discussion :-)
> > > > >
> > > > > For sure it would be nice to have a BT stack with more features!
> The
> > > > > BT has known issue of having different implementations of the stack
> > on
> > > > > different RTOS / OS / platforms, which is a known issue, and kinda
> > > > > mess because there is no common standard / approach /
> implementation,
> > > > > unfortunately around something that is supposed to be based on a
> > > > > common standard.
> > > > >
> > > > > Having common BT stack with other popular RTOS may make portability
> > > > > easier and developers move to NuttX in some cases.
> > > > >
> > > > > I understand that we are talking about this solution?
> > > > >
> > > > >
> > > > > https://docs.zephyrproject.org/latest/services/
> > > > connectivity/bluetooth/index.html
> > > > >
> > > > > In a perfect situation we would want to have modular implementation
> > in
> > > > > nuttx-apps just like nimble. This is pointed out by Xiang, Raiden,
> > and
> > > > > Alin already. But I understand some things may be hard to implement
> > > > > that way. I will follow the consensus here when ready, I have no
> > > > > strong opinion here, except any BT stack I touched before was a
> mess
> > > > > and I hope we can work out at least something decent :-P
> > > > >
> > > > > A bit offtopic but for kernel build we can take a look at quite old
> > > > > Bluetooth implementation on FreeBSD, where radio is provided by
> > ng_ubt
> > > > > (lower half in out case), then upper half uses standard HCI. Maybe
> > > > > something like this is possible in NuttX?
> > > > >
> > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > >
> > > > > Here is a quick overview article on the Bluetooth implementation in
> > > > > FreeBSD and Apple:
> > > > >
> > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > >
> > > > > Again it will be very nice to have fully featured BT stack in NuttX
> > > > > and I hope we can sort out the best possible porting implementation
> > > > > :-)
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <je...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > thanks Xiao and Raiden for your technical opinions which I also
> > share
> > > > so
> > > > > I
> > > > > > will not iterate them again.
> > > > > >
> > > > > > I am against merging this pr in NuttX repo
> > > > > > it should be splitted between nuttx and apps-repos and use POSIX
> > > > > > implementation as much as possible. We are focused on standards
> and
> > > > > > compatibility.
> > > > > >
> > > > > > Another concern is the license which does not match our ASF one
> and
> > > > does
> > > > > > not include any LICENSE file additions to clarify the compiance
> > > aspect
> > > > > >
> > > > > > Best regards
> > > > > > Alin J
> > > > > >
> > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> xiaoxiang781216@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > > So the real reason you've been objecting to my proposal is
> that
> > > > your
> > > > > team
> > > > > > > > has been working on something similar, correct?
> > > > > > > >
> > > > > > > > If you can give me a clear timeline for when your
> > implementation
> > > > > will be
> > > > > > > > submitted upstream, I'm happy to withdraw my PR and let your
> > code
> > > > > serve
> > > > > > > as
> > > > > > > > the baseline. I'm not here to fight over ownership of the
> > > Bluetooth
> > > > > > > stack.
> > > > > > > > My only motivation is that NuttX's lack of a capable
> Bluetooth
> > > > stack
> > > > > is
> > > > > > > > driving every developer toward Zephyr — and as a PMC member,
> I
> > > > think
> > > > > you
> > > > > > > > should be asking yourselves why this gap has remained
> unfilled
> > > for
> > > > so
> > > > > > > long.
> > > > > > > >
> > > > > > > >
> > > > > > > I object to landing the whole bluetooth stack into kernel space
> > > > > directly
> > > > > > > either yours and ours .
> > > > > > > This is the same feeling from raiden00pl too, let's see other
> > > > people's
> > > > > > > opinions here.
> > > > > > > But it's fine for me to host the whole code in nuttx-apps.git
> and
> > > > > refactor
> > > > > > > components to kernel
> > > > > > > space step by step.
> > > > > > >
> > > > > > >
> > > > > > > > As for the current PR, I'll remove the shell components from
> > the
> > > > > stack
> > > > > > > and
> > > > > > > > move them into apps/ where they belong. The base profiles
> > (A2DP,
> > > > BLE)
> > > > > > > will
> > > > > > > > stay in libc —
> > > > > > >
> > > > > > >
> > > > > > > The architecture is wrong to host any bluetooth profile in
> libc.
> > > > > > >
> > > > > > > in flat build mode this gives a significant performance
> > > > > > > > boost to the overall stack, which is the primary deployment
> > model
> > > > for
> > > > > > > most
> > > > > > > > NuttX devices.
> > > > > > > >
> > > > > > > >
> > > > > > > Performance should remain the same whether the base profile is
> > > hosted
> > > > > in
> > > > > > > libc or apps,
> > > > > > > could you point out any technical reason which impacts the
> > > > performance
> > > > > in
> > > > > > > the flat mode?
> > > > > > >
> > > > > > >
> > > > > > > > A few additional data points regarding our timeline: our
> > product
> > > is
> > > > > > > > scheduled for release in December, and Bluetooth SIG
> > > certification
> > > > is
> > > > > > > > already in progress — we expect to receive it around
> November.
> > If
> > > > the
> > > > > > > > baseline were to switch to your team's stack with its
> different
> > > > > > > > architecture, that certification cycle would need to be
> > repeated,
> > > > > which
> > > > > > > is
> > > > > > > > not trivial given the time and cost involved.
> > > > > > > >
> > > > > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五
> 15:08写道：
> > > > > > > >
> > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> magicdcps@gmail.com
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi raiden00pl,
> > > > > > > > > >
> > > > > > > > > > Regarding your point about the NimBLE port using the
> POSIX
> > > API
> > > > —
> > > > > yes,
> > > > > > > > it
> > > > > > > > > > uses POSIX, but there are real issues with the current
> > > > > implementation
> > > > > > > > > that
> > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical
> section
> > > > > > > > > >
> > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > >
> > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > >
> > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > {
> > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > return 0;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > This is a mutex, not a critical section. It does not
> > disable
> > > > > > > interrupts
> > > > > > > > > or
> > > > > > > > > > preemption — an ISR can still fire and corrupt data that
> > the
> > > > > > > "critical
> > > > > > > > > > section" was supposed to protect. On top of that, using a
> > > mutex
> > > > > opens
> > > > > > > > the
> > > > > > > > > > door to ABBA deadlocks when combined with any other lock
> > held
> > > > > inside
> > > > > > > > the
> > > > > > > > > > critical region:
> > > > > > > > > >
> > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> > > lock(mutex
> > > > > M) ←
> > > > > > > > > blocked
> > > > > > > > > > by B
> > > > > > > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ←
> > > > > blocked by
> > > > > > > A
> > > > > > > > > >
> > > > > > > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e.,
> actually
> > > > > disabling
> > > > > > > > > > scheduling/preemption). The current NuttX port simply
> does
> > > not
> > > > > meet
> > > > > > > the
> > > > > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > 2. Time subsystem uses clock_gettime instead of kernel
> tick
> > > > APIs
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > >
> > > > > > > > > > ble_npl_time_get() is backed by
> > > clock_gettime(CLOCK_MONOTONIC,
> > > > > ...),
> > > > > > > > > which
> > > > > > > > > > involves a syscall and floating-point arithmetic on every
> > > call.
> > > > > In a
> > > > > > > > BLE
> > > > > > > > > > stack where timestamps and timing are on the hot path,
> this
> > > > adds
> > > > > > > > > measurable
> > > > > > > > > > overhead compared to accessing the kernel tick counter
> > > > directly.
> > > > > > > > > > 3. Others are already using the kernel approach — and for
> > > good
> > > > > reason
> > > > > > > > > >
> > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > > > > > > openvela/NuttX
> > > > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > > > performance-critical
> > > > > > > > > > paths:
> > > > > > > > > >
> > > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > >
> > > > > > > > > > This isn't an academic exercise — it's a production
> choice.
> > > > They
> > > > > > > > > recognized
> > > > > > > > > > that a BLE stack needs tight integration with the OS
> timer
> > > > > subsystem,
> > > > > > > > > > direct access to critical section primitives, and
> efficient
> > > > event
> > > > > > > > > delivery,
> > > > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > > > My question
> > > > > > > > > >
> > > > > > > > > > If other organizations are already using a more
> performant,
> > > > > > > > > architecturally
> > > > > > > > > > correct kernel-level integration for their BLE stacks on
> > > NuttX,
> > > > > why
> > > > > > > > > should
> > > > > > > > > > we be told that we must use the slower, less correct
> POSIX
> > > > path?
> > > > > > > > NuttX's
> > > > > > > > > > POSIX compliance is valuable, but it shouldn't come at
> the
> > > cost
> > > > > of
> > > > > > > > > shipping
> > > > > > > > > > a BLE stack with a broken critical section primitive.
> There
> > > > > should be
> > > > > > > > > room
> > > > > > > > > > for both approaches, and the decision should be driven by
> > > > > technical
> > > > > > > > > merit,
> > > > > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > I don't object to moving the key bluetooth stack to kernel
> > > space
> > > > > like
> > > > > > > how
> > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > what I object to is that the current state of
> > > > > > > > > https://github.com/apache/nuttx/pull/20686 is far to move
> > > > entirely
> > > > > > > > > into kernel space.
> > > > > > > > > If I low my quality bar, I have requested my teammate to
> > > upstream
> > > > > our
> > > > > > > > > implementation:
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > since much work needs to be done before it can achieve the
> > > > quality
> > > > > > > > > upstream.
> > > > > > > > > BTW, many zephyr class BT features are developed by my team
> > and
> > > > > > > upstream
> > > > > > > > to
> > > > > > > > > Zeprhy community.
> > > > > > > > > If considering the quality, our version is much better
> since:
> > > > > > > > >
> > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at
> 2026.06
> > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi An Chao,
Isn't it possible to have a similar implementation that works for FLAT,
Protected and Kernel modes?
This way the maintenance will be easier. Only small kernel-specific parts
will remain there (as Raiden and Xiang proposed).
Suggestion: instead of naming it libs/libbt/, it would be better to use
libs/zblue to make it clear that it is a zblue port from Zephyr.
Let's use libs/libbt only for NuttX-specific (native) code.
And as I said, it is better to easily isolate the code that came from
Zephyr's zblue.
This way the user could select the Bluetooth stack they want without having
code from the other stack attached to it.
Also I suggest you to break your PR into smaller PRs; a single PR changing
more than 660K LoC is very massive.
BR,
Alan
On Fri, Oct 16, 2026 at 9:21 AM chao an <ma...@gmail.com> wrote:
> Hi Alan,
>
> Thank you for the thoughtful perspective and for engaging in the
> discussion.
>
> On security: we will maintain the Bluetooth stack ourselves and take
> responsibility for tracking and fixing vulnerabilities. I'm also confident
> that Xiaomi will contribute back on security issues given their ongoing
> investment in this codebase. This isn't a blind import — it's code that has
> active, committed maintainers behind it.
>
> Regarding the history with Greg: you're right that we discussed this years
> ago. But there's an important distinction — that earlier proposal placed
> the stack entirely in userspace. It did nothing to strengthen NuttX's
> kernel-level Bluetooth support. That's precisely why I'm back now,
> providing a kernel implementation this time around, which is what I
> committed to back then. Feel free to search the mailing list archives — the
> NuttX native Bluetooth stack will evolve from this baseline going forward.
>
> This implementation does not affect existing Bluetooth stacks in any way.
> Users can still choose NimBLE, the current NuttX BLE stack, or any other
> solution. This is an additional option, not a replacement. The goal is to
> give NuttX users more choices, not fewer.
>
> One more update: I just spoke with Xiaoxiang and we've reached some common
> ground. He's no longer opposed to the current stack implementation and
> agrees that the focus should be on proper structuring. Here's the plan
> going forward:
>
> 1. Unused shell code will be moved out of the stack and into apps/,
> running entirely in userspace.
> 2. Bluetooth profiles will be migrated to libs/libbt/, where we'll
> provide two OS API backends: a POSIX API implementation (for
> kernel/protected builds) and a NuttX kernel API implementation (for flat
> mode).
> 3. The L2CAP layer will remain in the NuttX kernel.
>
> This should address the architectural concerns while preserving the
> performance path for flat-mode deployments.
>
> Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
>
> > Hi An Chao,
> >
> > Thank you for trying to improve the NuttX Bluetooth support. And thank
> you
> > to bring this discussion here to let more people give their opinion.
> >
> > I think most of the concerns raised by Xiang and Raiden (Mateusz) are
> > important and need to be addressed.
> >
> > As I said at GitHub PR I think a main concern here is using the same
> > Bluetooth stack used on Zephyr, not because it is a bad stack (of course
> it
> > is not, it was developed by experts on Bluetooth area), but because we
> are
> > adding the same surface area of attack from Zephyr on NuttX.
> >
> > That means any security vulnerability affecting Zephyr BLE stack will
> > affect NuttX. It remove the protection that a companies could obtain when
> > using different RTOSs.
> >
> > Also, if my memory still serving me, I think Xiaomi team (you was there
> at
> > that time) already tried to submit their initial port of Zephyr BLE stack
> > to NuttX about 4 or 5 years ago and Greg was against it.
> >
> > His suggestion was to improve our BLE stack, that in fact has the same
> > origin of the Zephyr BLE stack (both came from a BLE stack from Intel
> > released as BSD license at that time).
> >
> > I'm not against including the Zephyr BLE stack, but it should be
> > selectable. Ideally the user should select if he/she wants to use NimBLE,
> > Zephyr or NuttX native BLE stack.
> >
> > BR,
> >
> > Alan
> >
> > On Friday, October 16, 2026, chao an <ma...@gmail.com> wrote:
> >
> > > Hi, Tomek,
> > >
> > > Thanks for the thoughtful input and the FreeBSD references — those are
> > very
> > > relevant to where we're heading.
> > >
> > > Just to set the context: NuttX's current Bluetooth stack only supports
> > BLE.
> > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing. This
> > is
> > > exactly why we want to bring a more complete Bluetooth stack to NuttX —
> > to
> > > catch up with what mainstream RTOS communities already offer.
> > >
> > > I actually agree with the FreeBSD/Apple architecture you referenced.
> Our
> > > end-state plan is similar: the L2CAP and HCI layers will live in the
> > > kernel, and a bluetoothd-style daemon will be implemented in libc,
> > managing
> > > profiles and higher-level protocols. This gives us a clean separation —
> > > transport in the kernel, policy and profiles in userspace — much like
> how
> > > FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1 of
> > > getting there incrementally.
> > >
> > > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> > >
> > > > Thank you An Chao for this proposition, work, and discussion :-)
> > > >
> > > > For sure it would be nice to have a BT stack with more features! The
> > > > BT has known issue of having different implementations of the stack
> on
> > > > different RTOS / OS / platforms, which is a known issue, and kinda
> > > > mess because there is no common standard / approach / implementation,
> > > > unfortunately around something that is supposed to be based on a
> > > > common standard.
> > > >
> > > > Having common BT stack with other popular RTOS may make portability
> > > > easier and developers move to NuttX in some cases.
> > > >
> > > > I understand that we are talking about this solution?
> > > >
> > > >
> > > > https://docs.zephyrproject.org/latest/services/
> > > connectivity/bluetooth/index.html
> > > >
> > > > In a perfect situation we would want to have modular implementation
> in
> > > > nuttx-apps just like nimble. This is pointed out by Xiang, Raiden,
> and
> > > > Alin already. But I understand some things may be hard to implement
> > > > that way. I will follow the consensus here when ready, I have no
> > > > strong opinion here, except any BT stack I touched before was a mess
> > > > and I hope we can work out at least something decent :-P
> > > >
> > > > A bit offtopic but for kernel build we can take a look at quite old
> > > > Bluetooth implementation on FreeBSD, where radio is provided by
> ng_ubt
> > > > (lower half in out case), then upper half uses standard HCI. Maybe
> > > > something like this is possible in NuttX?
> > > >
> > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > >
> > > > Here is a quick overview article on the Bluetooth implementation in
> > > > FreeBSD and Apple:
> > > >
> > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > >
> > > > Again it will be very nice to have fully featured BT stack in NuttX
> > > > and I hope we can sort out the best possible porting implementation
> > > > :-)
> > > >
> > > > --
> > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >
> > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <je...@gmail.com>
> > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > thanks Xiao and Raiden for your technical opinions which I also
> share
> > > so
> > > > I
> > > > > will not iterate them again.
> > > > >
> > > > > I am against merging this pr in NuttX repo
> > > > > it should be splitted between nuttx and apps-repos and use POSIX
> > > > > implementation as much as possible. We are focused on standards and
> > > > > compatibility.
> > > > >
> > > > > Another concern is the license which does not match our ASF one and
> > > does
> > > > > not include any LICENSE file additions to clarify the compiance
> > aspect
> > > > >
> > > > > Best regards
> > > > > Alin J
> > > > >
> > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com>
> > wrote:
> > > > > >
> > > > > > > So the real reason you've been objecting to my proposal is that
> > > your
> > > > team
> > > > > > > has been working on something similar, correct?
> > > > > > >
> > > > > > > If you can give me a clear timeline for when your
> implementation
> > > > will be
> > > > > > > submitted upstream, I'm happy to withdraw my PR and let your
> code
> > > > serve
> > > > > > as
> > > > > > > the baseline. I'm not here to fight over ownership of the
> > Bluetooth
> > > > > > stack.
> > > > > > > My only motivation is that NuttX's lack of a capable Bluetooth
> > > stack
> > > > is
> > > > > > > driving every developer toward Zephyr — and as a PMC member, I
> > > think
> > > > you
> > > > > > > should be asking yourselves why this gap has remained unfilled
> > for
> > > so
> > > > > > long.
> > > > > > >
> > > > > > >
> > > > > > I object to landing the whole bluetooth stack into kernel space
> > > > directly
> > > > > > either yours and ours .
> > > > > > This is the same feeling from raiden00pl too, let's see other
> > > people's
> > > > > > opinions here.
> > > > > > But it's fine for me to host the whole code in nuttx-apps.git and
> > > > refactor
> > > > > > components to kernel
> > > > > > space step by step.
> > > > > >
> > > > > >
> > > > > > > As for the current PR, I'll remove the shell components from
> the
> > > > stack
> > > > > > and
> > > > > > > move them into apps/ where they belong. The base profiles
> (A2DP,
> > > BLE)
> > > > > > will
> > > > > > > stay in libc —
> > > > > >
> > > > > >
> > > > > > The architecture is wrong to host any bluetooth profile in libc.
> > > > > >
> > > > > > in flat build mode this gives a significant performance
> > > > > > > boost to the overall stack, which is the primary deployment
> model
> > > for
> > > > > > most
> > > > > > > NuttX devices.
> > > > > > >
> > > > > > >
> > > > > > Performance should remain the same whether the base profile is
> > hosted
> > > > in
> > > > > > libc or apps,
> > > > > > could you point out any technical reason which impacts the
> > > performance
> > > > in
> > > > > > the flat mode?
> > > > > >
> > > > > >
> > > > > > > A few additional data points regarding our timeline: our
> product
> > is
> > > > > > > scheduled for release in December, and Bluetooth SIG
> > certification
> > > is
> > > > > > > already in progress — we expect to receive it around November.
> If
> > > the
> > > > > > > baseline were to switch to your team's stack with its different
> > > > > > > architecture, that certification cycle would need to be
> repeated,
> > > > which
> > > > > > is
> > > > > > > not trivial given the time and cost involved.
> > > > > > >
> > > > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > > > > > >
> > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <magicdcps@gmail.com
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Hi raiden00pl,
> > > > > > > > >
> > > > > > > > > Regarding your point about the NimBLE port using the POSIX
> > API
> > > —
> > > > yes,
> > > > > > > it
> > > > > > > > > uses POSIX, but there are real issues with the current
> > > > implementation
> > > > > > > > that
> > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > > > > > >
> > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > >
> > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > >
> > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > {
> > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > return 0;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > This is a mutex, not a critical section. It does not
> disable
> > > > > > interrupts
> > > > > > > > or
> > > > > > > > > preemption — an ISR can still fire and corrupt data that
> the
> > > > > > "critical
> > > > > > > > > section" was supposed to protect. On top of that, using a
> > mutex
> > > > opens
> > > > > > > the
> > > > > > > > > door to ABBA deadlocks when combined with any other lock
> held
> > > > inside
> > > > > > > the
> > > > > > > > > critical region:
> > > > > > > > >
> > > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> > lock(mutex
> > > > M) ←
> > > > > > > > blocked
> > > > > > > > > by B
> > > > > > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ←
> > > > blocked by
> > > > > > A
> > > > > > > > >
> > > > > > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> > > > disabling
> > > > > > > > > scheduling/preemption). The current NuttX port simply does
> > not
> > > > meet
> > > > > > the
> > > > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > 2. Time subsystem uses clock_gettime instead of kernel tick
> > > APIs
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > porting/npl/nuttx/src/os_time.c
> > > > > > > > >
> > > > > > > > > ble_npl_time_get() is backed by
> > clock_gettime(CLOCK_MONOTONIC,
> > > > ...),
> > > > > > > > which
> > > > > > > > > involves a syscall and floating-point arithmetic on every
> > call.
> > > > In a
> > > > > > > BLE
> > > > > > > > > stack where timestamps and timing are on the hot path, this
> > > adds
> > > > > > > > measurable
> > > > > > > > > overhead compared to accessing the kernel tick counter
> > > directly.
> > > > > > > > > 3. Others are already using the kernel approach — and for
> > good
> > > > reason
> > > > > > > > >
> > > > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > > > > > openvela/NuttX
> > > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > > performance-critical
> > > > > > > > > paths:
> > > > > > > > >
> > > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > >
> > > > > > > > > This isn't an academic exercise — it's a production choice.
> > > They
> > > > > > > > recognized
> > > > > > > > > that a BLE stack needs tight integration with the OS timer
> > > > subsystem,
> > > > > > > > > direct access to critical section primitives, and efficient
> > > event
> > > > > > > > delivery,
> > > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > > My question
> > > > > > > > >
> > > > > > > > > If other organizations are already using a more performant,
> > > > > > > > architecturally
> > > > > > > > > correct kernel-level integration for their BLE stacks on
> > NuttX,
> > > > why
> > > > > > > > should
> > > > > > > > > we be told that we must use the slower, less correct POSIX
> > > path?
> > > > > > > NuttX's
> > > > > > > > > POSIX compliance is valuable, but it shouldn't come at the
> > cost
> > > > of
> > > > > > > > shipping
> > > > > > > > > a BLE stack with a broken critical section primitive. There
> > > > should be
> > > > > > > > room
> > > > > > > > > for both approaches, and the decision should be driven by
> > > > technical
> > > > > > > > merit,
> > > > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > I don't object to moving the key bluetooth stack to kernel
> > space
> > > > like
> > > > > > how
> > > > > > > > the current bluetooth stack is done,
> > > > > > > > what I object to is that the current state of
> > > > > > > > https://github.com/apache/nuttx/pull/20686 is far to move
> > > entirely
> > > > > > > > into kernel space.
> > > > > > > > If I low my quality bar, I have requested my teammate to
> > upstream
> > > > our
> > > > > > > > implementation:
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > since much work needs to be done before it can achieve the
> > > quality
> > > > > > > > upstream.
> > > > > > > > BTW, many zephyr class BT features are developed by my team
> and
> > > > > > upstream
> > > > > > > to
> > > > > > > > Zeprhy community.
> > > > > > > > If considering the quality, our version is much better since:
> > > > > > > >
> > > > > > > > 1. Product on smart speaker last year
> > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > > > > > 3. Product on wear device by end of this year
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alan,
Thank you for the thoughtful perspective and for engaging in the discussion.
On security: we will maintain the Bluetooth stack ourselves and take
responsibility for tracking and fixing vulnerabilities. I'm also confident
that Xiaomi will contribute back on security issues given their ongoing
investment in this codebase. This isn't a blind import — it's code that has
active, committed maintainers behind it.
Regarding the history with Greg: you're right that we discussed this years
ago. But there's an important distinction — that earlier proposal placed
the stack entirely in userspace. It did nothing to strengthen NuttX's
kernel-level Bluetooth support. That's precisely why I'm back now,
providing a kernel implementation this time around, which is what I
committed to back then. Feel free to search the mailing list archives — the
NuttX native Bluetooth stack will evolve from this baseline going forward.
This implementation does not affect existing Bluetooth stacks in any way.
Users can still choose NimBLE, the current NuttX BLE stack, or any other
solution. This is an additional option, not a replacement. The goal is to
give NuttX users more choices, not fewer.
One more update: I just spoke with Xiaoxiang and we've reached some common
ground. He's no longer opposed to the current stack implementation and
agrees that the focus should be on proper structuring. Here's the plan
going forward:
1. Unused shell code will be moved out of the stack and into apps/,
running entirely in userspace.
2. Bluetooth profiles will be migrated to libs/libbt/, where we'll
provide two OS API backends: a POSIX API implementation (for
kernel/protected builds) and a NuttX kernel API implementation (for flat
mode).
3. The L2CAP layer will remain in the NuttX kernel.
This should address the architectural concerns while preserving the
performance path for flat-mode deployments.
Alan C. Assis <ac...@gmail.com> 于2026年10月16日周五 18:40写道：
> Hi An Chao,
>
> Thank you for trying to improve the NuttX Bluetooth support. And thank you
> to bring this discussion here to let more people give their opinion.
>
> I think most of the concerns raised by Xiang and Raiden (Mateusz) are
> important and need to be addressed.
>
> As I said at GitHub PR I think a main concern here is using the same
> Bluetooth stack used on Zephyr, not because it is a bad stack (of course it
> is not, it was developed by experts on Bluetooth area), but because we are
> adding the same surface area of attack from Zephyr on NuttX.
>
> That means any security vulnerability affecting Zephyr BLE stack will
> affect NuttX. It remove the protection that a companies could obtain when
> using different RTOSs.
>
> Also, if my memory still serving me, I think Xiaomi team (you was there at
> that time) already tried to submit their initial port of Zephyr BLE stack
> to NuttX about 4 or 5 years ago and Greg was against it.
>
> His suggestion was to improve our BLE stack, that in fact has the same
> origin of the Zephyr BLE stack (both came from a BLE stack from Intel
> released as BSD license at that time).
>
> I'm not against including the Zephyr BLE stack, but it should be
> selectable. Ideally the user should select if he/she wants to use NimBLE,
> Zephyr or NuttX native BLE stack.
>
> BR,
>
> Alan
>
> On Friday, October 16, 2026, chao an <ma...@gmail.com> wrote:
>
> > Hi, Tomek,
> >
> > Thanks for the thoughtful input and the FreeBSD references — those are
> very
> > relevant to where we're heading.
> >
> > Just to set the context: NuttX's current Bluetooth stack only supports
> BLE.
> > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing. This
> is
> > exactly why we want to bring a more complete Bluetooth stack to NuttX —
> to
> > catch up with what mainstream RTOS communities already offer.
> >
> > I actually agree with the FreeBSD/Apple architecture you referenced. Our
> > end-state plan is similar: the L2CAP and HCI layers will live in the
> > kernel, and a bluetoothd-style daemon will be implemented in libc,
> managing
> > profiles and higher-level protocols. This gives us a clean separation —
> > transport in the kernel, policy and profiles in userspace — much like how
> > FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1 of
> > getting there incrementally.
> >
> > Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> >
> > > Thank you An Chao for this proposition, work, and discussion :-)
> > >
> > > For sure it would be nice to have a BT stack with more features! The
> > > BT has known issue of having different implementations of the stack on
> > > different RTOS / OS / platforms, which is a known issue, and kinda
> > > mess because there is no common standard / approach / implementation,
> > > unfortunately around something that is supposed to be based on a
> > > common standard.
> > >
> > > Having common BT stack with other popular RTOS may make portability
> > > easier and developers move to NuttX in some cases.
> > >
> > > I understand that we are talking about this solution?
> > >
> > >
> > > https://docs.zephyrproject.org/latest/services/
> > connectivity/bluetooth/index.html
> > >
> > > In a perfect situation we would want to have modular implementation in
> > > nuttx-apps just like nimble. This is pointed out by Xiang, Raiden, and
> > > Alin already. But I understand some things may be hard to implement
> > > that way. I will follow the consensus here when ready, I have no
> > > strong opinion here, except any BT stack I touched before was a mess
> > > and I hope we can work out at least something decent :-P
> > >
> > > A bit offtopic but for kernel build we can take a look at quite old
> > > Bluetooth implementation on FreeBSD, where radio is provided by ng_ubt
> > > (lower half in out case), then upper half uses standard HCI. Maybe
> > > something like this is possible in NuttX?
> > >
> > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > >
> > > Here is a quick overview article on the Bluetooth implementation in
> > > FreeBSD and Apple:
> > >
> > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > >
> > > Again it will be very nice to have fully featured BT stack in NuttX
> > > and I hope we can sort out the best possible porting implementation
> > > :-)
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <je...@gmail.com>
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > thanks Xiao and Raiden for your technical opinions which I also share
> > so
> > > I
> > > > will not iterate them again.
> > > >
> > > > I am against merging this pr in NuttX repo
> > > > it should be splitted between nuttx and apps-repos and use POSIX
> > > > implementation as much as possible. We are focused on standards and
> > > > compatibility.
> > > >
> > > > Another concern is the license which does not match our ASF one and
> > does
> > > > not include any LICENSE file additions to clarify the compiance
> aspect
> > > >
> > > > Best regards
> > > > Alin J
> > > >
> > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com>
> > > wrote:
> > > >
> > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com>
> wrote:
> > > > >
> > > > > > So the real reason you've been objecting to my proposal is that
> > your
> > > team
> > > > > > has been working on something similar, correct?
> > > > > >
> > > > > > If you can give me a clear timeline for when your implementation
> > > will be
> > > > > > submitted upstream, I'm happy to withdraw my PR and let your code
> > > serve
> > > > > as
> > > > > > the baseline. I'm not here to fight over ownership of the
> Bluetooth
> > > > > stack.
> > > > > > My only motivation is that NuttX's lack of a capable Bluetooth
> > stack
> > > is
> > > > > > driving every developer toward Zephyr — and as a PMC member, I
> > think
> > > you
> > > > > > should be asking yourselves why this gap has remained unfilled
> for
> > so
> > > > > long.
> > > > > >
> > > > > >
> > > > > I object to landing the whole bluetooth stack into kernel space
> > > directly
> > > > > either yours and ours .
> > > > > This is the same feeling from raiden00pl too, let's see other
> > people's
> > > > > opinions here.
> > > > > But it's fine for me to host the whole code in nuttx-apps.git and
> > > refactor
> > > > > components to kernel
> > > > > space step by step.
> > > > >
> > > > >
> > > > > > As for the current PR, I'll remove the shell components from the
> > > stack
> > > > > and
> > > > > > move them into apps/ where they belong. The base profiles (A2DP,
> > BLE)
> > > > > will
> > > > > > stay in libc —
> > > > >
> > > > >
> > > > > The architecture is wrong to host any bluetooth profile in libc.
> > > > >
> > > > > in flat build mode this gives a significant performance
> > > > > > boost to the overall stack, which is the primary deployment model
> > for
> > > > > most
> > > > > > NuttX devices.
> > > > > >
> > > > > >
> > > > > Performance should remain the same whether the base profile is
> hosted
> > > in
> > > > > libc or apps,
> > > > > could you point out any technical reason which impacts the
> > performance
> > > in
> > > > > the flat mode?
> > > > >
> > > > >
> > > > > > A few additional data points regarding our timeline: our product
> is
> > > > > > scheduled for release in December, and Bluetooth SIG
> certification
> > is
> > > > > > already in progress — we expect to receive it around November. If
> > the
> > > > > > baseline were to switch to your team's stack with its different
> > > > > > architecture, that certification cycle would need to be repeated,
> > > which
> > > > > is
> > > > > > not trivial given the time and cost involved.
> > > > > >
> > > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > > > > >
> > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > > Hi raiden00pl,
> > > > > > > >
> > > > > > > > Regarding your point about the NimBLE port using the POSIX
> API
> > —
> > > yes,
> > > > > > it
> > > > > > > > uses POSIX, but there are real issues with the current
> > > implementation
> > > > > > > that
> > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > > > > >
> > > > > > > > Look at the NuttX port's implementation:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > https://github.com/apache/mynewt-nimble/blob/master/
> > porting/npl/nuttx/src/os_atomic.c
> > > > > > > >
> > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > >
> > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > {
> > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > return 0;
> > > > > > > > }
> > > > > > > >
> > > > > > > > This is a mutex, not a critical section. It does not disable
> > > > > interrupts
> > > > > > > or
> > > > > > > > preemption — an ISR can still fire and corrupt data that the
> > > > > "critical
> > > > > > > > section" was supposed to protect. On top of that, using a
> mutex
> > > opens
> > > > > > the
> > > > > > > > door to ABBA deadlocks when combined with any other lock held
> > > inside
> > > > > > the
> > > > > > > > critical region:
> > > > > > > >
> > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> lock(mutex
> > > M) ←
> > > > > > > blocked
> > > > > > > > by B
> > > > > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ←
> > > blocked by
> > > > > A
> > > > > > > >
> > > > > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> > > disabling
> > > > > > > > scheduling/preemption). The current NuttX port simply does
> not
> > > meet
> > > > > the
> > > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > 2. Time subsystem uses clock_gettime instead of kernel tick
> > APIs
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > https://github.com/apache/mynewt-nimble/blob/master/
> > porting/npl/nuttx/src/os_time.c
> > > > > > > >
> > > > > > > > ble_npl_time_get() is backed by
> clock_gettime(CLOCK_MONOTONIC,
> > > ...),
> > > > > > > which
> > > > > > > > involves a syscall and floating-point arithmetic on every
> call.
> > > In a
> > > > > > BLE
> > > > > > > > stack where timestamps and timing are on the hot path, this
> > adds
> > > > > > > measurable
> > > > > > > > overhead compared to accessing the kernel tick counter
> > directly.
> > > > > > > > 3. Others are already using the kernel approach — and for
> good
> > > reason
> > > > > > > >
> > > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > > > > openvela/NuttX
> > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > performance-critical
> > > > > > > > paths:
> > > > > > > >
> > > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > >
> > > > > > > > This isn't an academic exercise — it's a production choice.
> > They
> > > > > > > recognized
> > > > > > > > that a BLE stack needs tight integration with the OS timer
> > > subsystem,
> > > > > > > > direct access to critical section primitives, and efficient
> > event
> > > > > > > delivery,
> > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > My question
> > > > > > > >
> > > > > > > > If other organizations are already using a more performant,
> > > > > > > architecturally
> > > > > > > > correct kernel-level integration for their BLE stacks on
> NuttX,
> > > why
> > > > > > > should
> > > > > > > > we be told that we must use the slower, less correct POSIX
> > path?
> > > > > > NuttX's
> > > > > > > > POSIX compliance is valuable, but it shouldn't come at the
> cost
> > > of
> > > > > > > shipping
> > > > > > > > a BLE stack with a broken critical section primitive. There
> > > should be
> > > > > > > room
> > > > > > > > for both approaches, and the decision should be driven by
> > > technical
> > > > > > > merit,
> > > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > > >
> > > > > > > >
> > > > > > > I don't object to moving the key bluetooth stack to kernel
> space
> > > like
> > > > > how
> > > > > > > the current bluetooth stack is done,
> > > > > > > what I object to is that the current state of
> > > > > > > https://github.com/apache/nuttx/pull/20686 is far to move
> > entirely
> > > > > > > into kernel space.
> > > > > > > If I low my quality bar, I have requested my teammate to
> upstream
> > > our
> > > > > > > implementation:
> > > > > > >
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > since much work needs to be done before it can achieve the
> > quality
> > > > > > > upstream.
> > > > > > > BTW, many zephyr class BT features are developed by my team and
> > > > > upstream
> > > > > > to
> > > > > > > Zeprhy community.
> > > > > > > If considering the quality, our version is much better since:
> > > > > > >
> > > > > > > 1. Product on smart speaker last year
> > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > > > > 3. Product on wear device by end of this year
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi An Chao,
Thank you for trying to improve the NuttX Bluetooth support. And thank you
to bring this discussion here to let more people give their opinion.
I think most of the concerns raised by Xiang and Raiden (Mateusz) are
important and need to be addressed.
As I said at GitHub PR I think a main concern here is using the same
Bluetooth stack used on Zephyr, not because it is a bad stack (of course it
is not, it was developed by experts on Bluetooth area), but because we are
adding the same surface area of attack from Zephyr on NuttX.
That means any security vulnerability affecting Zephyr BLE stack will
affect NuttX. It remove the protection that a companies could obtain when
using different RTOSs.
Also, if my memory still serving me, I think Xiaomi team (you was there at
that time) already tried to submit their initial port of Zephyr BLE stack
to NuttX about 4 or 5 years ago and Greg was against it.
His suggestion was to improve our BLE stack, that in fact has the same
origin of the Zephyr BLE stack (both came from a BLE stack from Intel
released as BSD license at that time).
I'm not against including the Zephyr BLE stack, but it should be
selectable. Ideally the user should select if he/she wants to use NimBLE,
Zephyr or NuttX native BLE stack.
BR,
Alan
On Friday, October 16, 2026, chao an <ma...@gmail.com> wrote:
> Hi, Tomek,
>
> Thanks for the thoughtful input and the FreeBSD references — those are very
> relevant to where we're heading.
>
> Just to set the context: NuttX's current Bluetooth stack only supports BLE.
> Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing. This is
> exactly why we want to bring a more complete Bluetooth stack to NuttX — to
> catch up with what mainstream RTOS communities already offer.
>
> I actually agree with the FreeBSD/Apple architecture you referenced. Our
> end-state plan is similar: the L2CAP and HCI layers will live in the
> kernel, and a bluetoothd-style daemon will be implemented in libc, managing
> profiles and higher-level protocols. This gives us a clean separation —
> transport in the kernel, policy and profiles in userspace — much like how
> FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1 of
> getting there incrementally.
>
> Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
>
> > Thank you An Chao for this proposition, work, and discussion :-)
> >
> > For sure it would be nice to have a BT stack with more features! The
> > BT has known issue of having different implementations of the stack on
> > different RTOS / OS / platforms, which is a known issue, and kinda
> > mess because there is no common standard / approach / implementation,
> > unfortunately around something that is supposed to be based on a
> > common standard.
> >
> > Having common BT stack with other popular RTOS may make portability
> > easier and developers move to NuttX in some cases.
> >
> > I understand that we are talking about this solution?
> >
> >
> > https://docs.zephyrproject.org/latest/services/
> connectivity/bluetooth/index.html
> >
> > In a perfect situation we would want to have modular implementation in
> > nuttx-apps just like nimble. This is pointed out by Xiang, Raiden, and
> > Alin already. But I understand some things may be hard to implement
> > that way. I will follow the consensus here when ready, I have no
> > strong opinion here, except any BT stack I touched before was a mess
> > and I hope we can work out at least something decent :-P
> >
> > A bit offtopic but for kernel build we can take a look at quite old
> > Bluetooth implementation on FreeBSD, where radio is provided by ng_ubt
> > (lower half in out case), then upper half uses standard HCI. Maybe
> > something like this is possible in NuttX?
> >
> > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> >
> > Here is a quick overview article on the Bluetooth implementation in
> > FreeBSD and Apple:
> >
> > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> >
> > Again it will be very nice to have fully featured BT stack in NuttX
> > and I hope we can sort out the best possible porting implementation
> > :-)
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
> > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <je...@gmail.com>
> wrote:
> > >
> > > Hi,
> > >
> > > thanks Xiao and Raiden for your technical opinions which I also share
> so
> > I
> > > will not iterate them again.
> > >
> > > I am against merging this pr in NuttX repo
> > > it should be splitted between nuttx and apps-repos and use POSIX
> > > implementation as much as possible. We are focused on standards and
> > > compatibility.
> > >
> > > Another concern is the license which does not match our ASF one and
> does
> > > not include any LICENSE file additions to clarify the compiance aspect
> > >
> > > Best regards
> > > Alin J
> > >
> > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com>
> > wrote:
> > >
> > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> > > >
> > > > > So the real reason you've been objecting to my proposal is that
> your
> > team
> > > > > has been working on something similar, correct?
> > > > >
> > > > > If you can give me a clear timeline for when your implementation
> > will be
> > > > > submitted upstream, I'm happy to withdraw my PR and let your code
> > serve
> > > > as
> > > > > the baseline. I'm not here to fight over ownership of the Bluetooth
> > > > stack.
> > > > > My only motivation is that NuttX's lack of a capable Bluetooth
> stack
> > is
> > > > > driving every developer toward Zephyr — and as a PMC member, I
> think
> > you
> > > > > should be asking yourselves why this gap has remained unfilled for
> so
> > > > long.
> > > > >
> > > > >
> > > > I object to landing the whole bluetooth stack into kernel space
> > directly
> > > > either yours and ours .
> > > > This is the same feeling from raiden00pl too, let's see other
> people's
> > > > opinions here.
> > > > But it's fine for me to host the whole code in nuttx-apps.git and
> > refactor
> > > > components to kernel
> > > > space step by step.
> > > >
> > > >
> > > > > As for the current PR, I'll remove the shell components from the
> > stack
> > > > and
> > > > > move them into apps/ where they belong. The base profiles (A2DP,
> BLE)
> > > > will
> > > > > stay in libc —
> > > >
> > > >
> > > > The architecture is wrong to host any bluetooth profile in libc.
> > > >
> > > > in flat build mode this gives a significant performance
> > > > > boost to the overall stack, which is the primary deployment model
> for
> > > > most
> > > > > NuttX devices.
> > > > >
> > > > >
> > > > Performance should remain the same whether the base profile is hosted
> > in
> > > > libc or apps,
> > > > could you point out any technical reason which impacts the
> performance
> > in
> > > > the flat mode?
> > > >
> > > >
> > > > > A few additional data points regarding our timeline: our product is
> > > > > scheduled for release in December, and Bluetooth SIG certification
> is
> > > > > already in progress — we expect to receive it around November. If
> the
> > > > > baseline were to switch to your team's stack with its different
> > > > > architecture, that certification cycle would need to be repeated,
> > which
> > > > is
> > > > > not trivial given the time and cost involved.
> > > > >
> > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > > > >
> > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com>
> > wrote:
> > > > > >
> > > > > > > Hi raiden00pl,
> > > > > > >
> > > > > > > Regarding your point about the NimBLE port using the POSIX API
> —
> > yes,
> > > > > it
> > > > > > > uses POSIX, but there are real issues with the current
> > implementation
> > > > > > that
> > > > > > > go beyond just kernel/protected mode support.
> > > > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > > > >
> > > > > > > Look at the NuttX port's implementation:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/mynewt-nimble/blob/master/
> porting/npl/nuttx/src/os_atomic.c
> > > > > > >
> > > > > > > static pthread_mutex_t s_mutex =
> > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > >
> > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > {
> > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > This is a mutex, not a critical section. It does not disable
> > > > interrupts
> > > > > > or
> > > > > > > preemption — an ISR can still fire and corrupt data that the
> > > > "critical
> > > > > > > section" was supposed to protect. On top of that, using a mutex
> > opens
> > > > > the
> > > > > > > door to ABBA deadlocks when combined with any other lock held
> > inside
> > > > > the
> > > > > > > critical region:
> > > > > > >
> > > > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex
> > M) ←
> > > > > > blocked
> > > > > > > by B
> > > > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ←
> > blocked by
> > > > A
> > > > > > >
> > > > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> > disabling
> > > > > > > scheduling/preemption). The current NuttX port simply does not
> > meet
> > > > the
> > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > ble_npl_hw_enter_critical.
> > > > > > > 2. Time subsystem uses clock_gettime instead of kernel tick
> APIs
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/mynewt-nimble/blob/master/
> porting/npl/nuttx/src/os_time.c
> > > > > > >
> > > > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC,
> > ...),
> > > > > > which
> > > > > > > involves a syscall and floating-point arithmetic on every call.
> > In a
> > > > > BLE
> > > > > > > stack where timestamps and timing are on the hot path, this
> adds
> > > > > > measurable
> > > > > > > overhead compared to accessing the kernel tick counter
> directly.
> > > > > > > 3. Others are already using the kernel approach — and for good
> > reason
> > > > > > >
> > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > > > openvela/NuttX
> > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > performance-critical
> > > > > > > paths:
> > > > > > >
> > > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > >
> > > > > > > This isn't an academic exercise — it's a production choice.
> They
> > > > > > recognized
> > > > > > > that a BLE stack needs tight integration with the OS timer
> > subsystem,
> > > > > > > direct access to critical section primitives, and efficient
> event
> > > > > > delivery,
> > > > > > > none of which POSIX provides well in this context.
> > > > > > > My question
> > > > > > >
> > > > > > > If other organizations are already using a more performant,
> > > > > > architecturally
> > > > > > > correct kernel-level integration for their BLE stacks on NuttX,
> > why
> > > > > > should
> > > > > > > we be told that we must use the slower, less correct POSIX
> path?
> > > > > NuttX's
> > > > > > > POSIX compliance is valuable, but it shouldn't come at the cost
> > of
> > > > > > shipping
> > > > > > > a BLE stack with a broken critical section primitive. There
> > should be
> > > > > > room
> > > > > > > for both approaches, and the decision should be driven by
> > technical
> > > > > > merit,
> > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > >
> > > > > > >
> > > > > > I don't object to moving the key bluetooth stack to kernel space
> > like
> > > > how
> > > > > > the current bluetooth stack is done,
> > > > > > what I object to is that the current state of
> > > > > > https://github.com/apache/nuttx/pull/20686 is far to move
> entirely
> > > > > > into kernel space.
> > > > > > If I low my quality bar, I have requested my teammate to upstream
> > our
> > > > > > implementation:
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > since much work needs to be done before it can achieve the
> quality
> > > > > > upstream.
> > > > > > BTW, many zephyr class BT features are developed by my team and
> > > > upstream
> > > > > to
> > > > > > Zeprhy community.
> > > > > > If considering the quality, our version is much better since:
> > > > > >
> > > > > > 1. Product on smart speaker last year
> > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > > > 3. Product on wear device by end of this year
> > > > > >
> > > > >
> > > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi, Tomek,
Thanks for the thoughtful input and the FreeBSD references — those are very
relevant to where we're heading.
Just to set the context: NuttX's current Bluetooth stack only supports BLE.
Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing. This is
exactly why we want to bring a more complete Bluetooth stack to NuttX — to
catch up with what mainstream RTOS communities already offer.
I actually agree with the FreeBSD/Apple architecture you referenced. Our
end-state plan is similar: the L2CAP and HCI layers will live in the
kernel, and a bluetoothd-style daemon will be implemented in libc, managing
profiles and higher-level protocols. This gives us a clean separation —
transport in the kernel, policy and profiles in userspace — much like how
FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1 of
getting there incrementally.
Tomek CEDRO <to...@cedro.info> 于2026年10月16日周五 17:07写道：
> Thank you An Chao for this proposition, work, and discussion :-)
>
> For sure it would be nice to have a BT stack with more features! The
> BT has known issue of having different implementations of the stack on
> different RTOS / OS / platforms, which is a known issue, and kinda
> mess because there is no common standard / approach / implementation,
> unfortunately around something that is supposed to be based on a
> common standard.
>
> Having common BT stack with other popular RTOS may make portability
> easier and developers move to NuttX in some cases.
>
> I understand that we are talking about this solution?
>
>
> https://docs.zephyrproject.org/latest/services/connectivity/bluetooth/index.html
>
> In a perfect situation we would want to have modular implementation in
> nuttx-apps just like nimble. This is pointed out by Xiang, Raiden, and
> Alin already. But I understand some things may be hard to implement
> that way. I will follow the consensus here when ready, I have no
> strong opinion here, except any BT stack I touched before was a mess
> and I hope we can work out at least something decent :-P
>
> A bit offtopic but for kernel build we can take a look at quite old
> Bluetooth implementation on FreeBSD, where radio is provided by ng_ubt
> (lower half in out case), then upper half uses standard HCI. Maybe
> something like this is possible in NuttX?
>
> 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
>
> Here is a quick overview article on the Bluetooth implementation in
> FreeBSD and Apple:
>
> https://pkgdemon.github.io/freebsd-bluetooth-management.html
>
> Again it will be very nice to have fully featured BT stack in NuttX
> and I hope we can sort out the best possible porting implementation
> :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <je...@gmail.com> wrote:
> >
> > Hi,
> >
> > thanks Xiao and Raiden for your technical opinions which I also share so
> I
> > will not iterate them again.
> >
> > I am against merging this pr in NuttX repo
> > it should be splitted between nuttx and apps-repos and use POSIX
> > implementation as much as possible. We are focused on standards and
> > compatibility.
> >
> > Another concern is the license which does not match our ASF one and does
> > not include any LICENSE file additions to clarify the compiance aspect
> >
> > Best regards
> > Alin J
> >
> > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com>
> wrote:
> >
> > > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> > >
> > > > So the real reason you've been objecting to my proposal is that your
> team
> > > > has been working on something similar, correct?
> > > >
> > > > If you can give me a clear timeline for when your implementation
> will be
> > > > submitted upstream, I'm happy to withdraw my PR and let your code
> serve
> > > as
> > > > the baseline. I'm not here to fight over ownership of the Bluetooth
> > > stack.
> > > > My only motivation is that NuttX's lack of a capable Bluetooth stack
> is
> > > > driving every developer toward Zephyr — and as a PMC member, I think
> you
> > > > should be asking yourselves why this gap has remained unfilled for so
> > > long.
> > > >
> > > >
> > > I object to landing the whole bluetooth stack into kernel space
> directly
> > > either yours and ours .
> > > This is the same feeling from raiden00pl too, let's see other people's
> > > opinions here.
> > > But it's fine for me to host the whole code in nuttx-apps.git and
> refactor
> > > components to kernel
> > > space step by step.
> > >
> > >
> > > > As for the current PR, I'll remove the shell components from the
> stack
> > > and
> > > > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> > > will
> > > > stay in libc —
> > >
> > >
> > > The architecture is wrong to host any bluetooth profile in libc.
> > >
> > > in flat build mode this gives a significant performance
> > > > boost to the overall stack, which is the primary deployment model for
> > > most
> > > > NuttX devices.
> > > >
> > > >
> > > Performance should remain the same whether the base profile is hosted
> in
> > > libc or apps,
> > > could you point out any technical reason which impacts the performance
> in
> > > the flat mode?
> > >
> > >
> > > > A few additional data points regarding our timeline: our product is
> > > > scheduled for release in December, and Bluetooth SIG certification is
> > > > already in progress — we expect to receive it around November. If the
> > > > baseline were to switch to your team's stack with its different
> > > > architecture, that certification cycle would need to be repeated,
> which
> > > is
> > > > not trivial given the time and cost involved.
> > > >
> > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > > >
> > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com>
> wrote:
> > > > >
> > > > > > Hi raiden00pl,
> > > > > >
> > > > > > Regarding your point about the NimBLE port using the POSIX API —
> yes,
> > > > it
> > > > > > uses POSIX, but there are real issues with the current
> implementation
> > > > > that
> > > > > > go beyond just kernel/protected mode support.
> > > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > > >
> > > > > > Look at the NuttX port's implementation:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > > > >
> > > > > > static pthread_mutex_t s_mutex =
> > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > >
> > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > {
> > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > This is a mutex, not a critical section. It does not disable
> > > interrupts
> > > > > or
> > > > > > preemption — an ISR can still fire and corrupt data that the
> > > "critical
> > > > > > section" was supposed to protect. On top of that, using a mutex
> opens
> > > > the
> > > > > > door to ABBA deadlocks when combined with any other lock held
> inside
> > > > the
> > > > > > critical region:
> > > > > >
> > > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex
> M) ←
> > > > > blocked
> > > > > > by B
> > > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ←
> blocked by
> > > A
> > > > > >
> > > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> disabling
> > > > > > scheduling/preemption). The current NuttX port simply does not
> meet
> > > the
> > > > > > semantic contract that the NimBLE stack expects from
> > > > > > ble_npl_hw_enter_critical.
> > > > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > > > >
> > > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC,
> ...),
> > > > > which
> > > > > > involves a syscall and floating-point arithmetic on every call.
> In a
> > > > BLE
> > > > > > stack where timestamps and timing are on the hot path, this adds
> > > > > measurable
> > > > > > overhead compared to accessing the kernel tick counter directly.
> > > > > > 3. Others are already using the kernel approach — and for good
> reason
> > > > > >
> > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > > openvela/NuttX
> > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > performance-critical
> > > > > > paths:
> > > > > >
> > > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > >
> > > > > > This isn't an academic exercise — it's a production choice. They
> > > > > recognized
> > > > > > that a BLE stack needs tight integration with the OS timer
> subsystem,
> > > > > > direct access to critical section primitives, and efficient event
> > > > > delivery,
> > > > > > none of which POSIX provides well in this context.
> > > > > > My question
> > > > > >
> > > > > > If other organizations are already using a more performant,
> > > > > architecturally
> > > > > > correct kernel-level integration for their BLE stacks on NuttX,
> why
> > > > > should
> > > > > > we be told that we must use the slower, less correct POSIX path?
> > > > NuttX's
> > > > > > POSIX compliance is valuable, but it shouldn't come at the cost
> of
> > > > > shipping
> > > > > > a BLE stack with a broken critical section primitive. There
> should be
> > > > > room
> > > > > > for both approaches, and the decision should be driven by
> technical
> > > > > merit,
> > > > > > not by treating POSIX as the only acceptable answer.
> > > > > >
> > > > > >
> > > > > I don't object to moving the key bluetooth stack to kernel space
> like
> > > how
> > > > > the current bluetooth stack is done,
> > > > > what I object to is that the current state of
> > > > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > > > into kernel space.
> > > > > If I low my quality bar, I have requested my teammate to upstream
> our
> > > > > implementation:
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > since much work needs to be done before it can achieve the quality
> > > > > upstream.
> > > > > BTW, many zephyr class BT features are developed by my team and
> > > upstream
> > > > to
> > > > > Zeprhy community.
> > > > > If considering the quality, our version is much better since:
> > > > >
> > > > > 1. Product on smart speaker last year
> > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > > 3. Product on wear device by end of this year
> > > > >
> > > >
> > >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Tomek CEDRO <to...@cedro.info>.
Thank you An Chao for this proposition, work, and discussion :-)
For sure it would be nice to have a BT stack with more features! The
BT has known issue of having different implementations of the stack on
different RTOS / OS / platforms, which is a known issue, and kinda
mess because there is no common standard / approach / implementation,
unfortunately around something that is supposed to be based on a
common standard.
Having common BT stack with other popular RTOS may make portability
easier and developers move to NuttX in some cases.
I understand that we are talking about this solution?
https://docs.zephyrproject.org/latest/services/connectivity/bluetooth/index.html
In a perfect situation we would want to have modular implementation in
nuttx-apps just like nimble. This is pointed out by Xiang, Raiden, and
Alin already. But I understand some things may be hard to implement
that way. I will follow the consensus here when ready, I have no
strong opinion here, except any BT stack I touched before was a mess
and I hope we can work out at least something decent :-P
A bit offtopic but for kernel build we can take a look at quite old
Bluetooth implementation on FreeBSD, where radio is provided by ng_ubt
(lower half in out case), then upper half uses standard HCI. Maybe
something like this is possible in NuttX?
1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
Here is a quick overview article on the Bluetooth implementation in
FreeBSD and Apple:
https://pkgdemon.github.io/freebsd-bluetooth-management.html
Again it will be very nice to have fully featured BT stack in NuttX
and I hope we can sort out the best possible porting implementation
:-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <je...@gmail.com> wrote:
>
> Hi,
>
> thanks Xiao and Raiden for your technical opinions which I also share so I
> will not iterate them again.
>
> I am against merging this pr in NuttX repo
> it should be splitted between nuttx and apps-repos and use POSIX
> implementation as much as possible. We are focused on standards and
> compatibility.
>
> Another concern is the license which does not match our ASF one and does
> not include any LICENSE file additions to clarify the compiance aspect
>
> Best regards
> Alin J
>
> On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com> wrote:
>
> > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> >
> > > So the real reason you've been objecting to my proposal is that your team
> > > has been working on something similar, correct?
> > >
> > > If you can give me a clear timeline for when your implementation will be
> > > submitted upstream, I'm happy to withdraw my PR and let your code serve
> > as
> > > the baseline. I'm not here to fight over ownership of the Bluetooth
> > stack.
> > > My only motivation is that NuttX's lack of a capable Bluetooth stack is
> > > driving every developer toward Zephyr — and as a PMC member, I think you
> > > should be asking yourselves why this gap has remained unfilled for so
> > long.
> > >
> > >
> > I object to landing the whole bluetooth stack into kernel space directly
> > either yours and ours .
> > This is the same feeling from raiden00pl too, let's see other people's
> > opinions here.
> > But it's fine for me to host the whole code in nuttx-apps.git and refactor
> > components to kernel
> > space step by step.
> >
> >
> > > As for the current PR, I'll remove the shell components from the stack
> > and
> > > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> > will
> > > stay in libc —
> >
> >
> > The architecture is wrong to host any bluetooth profile in libc.
> >
> > in flat build mode this gives a significant performance
> > > boost to the overall stack, which is the primary deployment model for
> > most
> > > NuttX devices.
> > >
> > >
> > Performance should remain the same whether the base profile is hosted in
> > libc or apps,
> > could you point out any technical reason which impacts the performance in
> > the flat mode?
> >
> >
> > > A few additional data points regarding our timeline: our product is
> > > scheduled for release in December, and Bluetooth SIG certification is
> > > already in progress — we expect to receive it around November. If the
> > > baseline were to switch to your team's stack with its different
> > > architecture, that certification cycle would need to be repeated, which
> > is
> > > not trivial given the time and cost involved.
> > >
> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > >
> > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> > > >
> > > > > Hi raiden00pl,
> > > > >
> > > > > Regarding your point about the NimBLE port using the POSIX API — yes,
> > > it
> > > > > uses POSIX, but there are real issues with the current implementation
> > > > that
> > > > > go beyond just kernel/protected mode support.
> > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > >
> > > > > Look at the NuttX port's implementation:
> > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > > >
> > > > > static pthread_mutex_t s_mutex =
> > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > >
> > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > {
> > > > > pthread_mutex_lock(&s_mutex);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > This is a mutex, not a critical section. It does not disable
> > interrupts
> > > > or
> > > > > preemption — an ISR can still fire and corrupt data that the
> > "critical
> > > > > section" was supposed to protect. On top of that, using a mutex opens
> > > the
> > > > > door to ABBA deadlocks when combined with any other lock held inside
> > > the
> > > > > critical region:
> > > > >
> > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > > > blocked
> > > > > by B
> > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by
> > A
> > > > >
> > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > > > scheduling/preemption). The current NuttX port simply does not meet
> > the
> > > > > semantic contract that the NimBLE stack expects from
> > > > > ble_npl_hw_enter_critical.
> > > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > > >
> > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > > > which
> > > > > involves a syscall and floating-point arithmetic on every call. In a
> > > BLE
> > > > > stack where timestamps and timing are on the hot path, this adds
> > > > measurable
> > > > > overhead compared to accessing the kernel tick counter directly.
> > > > > 3. Others are already using the kernel approach — and for good reason
> > > > >
> > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > openvela/NuttX
> > > > > uses kernel APIs directly, bypassing POSIX for the
> > performance-critical
> > > > > paths:
> > > > >
> > > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > >
> > > > > This isn't an academic exercise — it's a production choice. They
> > > > recognized
> > > > > that a BLE stack needs tight integration with the OS timer subsystem,
> > > > > direct access to critical section primitives, and efficient event
> > > > delivery,
> > > > > none of which POSIX provides well in this context.
> > > > > My question
> > > > >
> > > > > If other organizations are already using a more performant,
> > > > architecturally
> > > > > correct kernel-level integration for their BLE stacks on NuttX, why
> > > > should
> > > > > we be told that we must use the slower, less correct POSIX path?
> > > NuttX's
> > > > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > > > shipping
> > > > > a BLE stack with a broken critical section primitive. There should be
> > > > room
> > > > > for both approaches, and the decision should be driven by technical
> > > > merit,
> > > > > not by treating POSIX as the only acceptable answer.
> > > > >
> > > > >
> > > > I don't object to moving the key bluetooth stack to kernel space like
> > how
> > > > the current bluetooth stack is done,
> > > > what I object to is that the current state of
> > > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > > into kernel space.
> > > > If I low my quality bar, I have requested my teammate to upstream our
> > > > implementation:
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > since much work needs to be done before it can achieve the quality
> > > > upstream.
> > > > BTW, many zephyr class BT features are developed by my team and
> > upstream
> > > to
> > > > Zeprhy community.
> > > > If considering the quality, our version is much better since:
> > > >
> > > > 1. Product on smart speaker last year
> > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > 3. Product on wear device by end of this year
> > > >
> > >
> >
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alin,
I think it's premature to draw that conclusion. We are still actively
discussing the implementation approach — whether components end up in libc
or in apps/ is a technical decision that's being debated right now, and
we've already stated that we will follow POSIX standards in the final
architecture. The current PR is Phase 1 of an incremental process, not the
end state.
Regarding licensing, that's a fair concern and we'll address it before
anything lands.
Please don't dismiss the work before the discussion has run its course.
Alin Jerpelea <je...@gmail.com> 于2026年10月16日周五 16:39写道：
> Hi,
>
> thanks Xiao and Raiden for your technical opinions which I also share so I
> will not iterate them again.
>
> I am against merging this pr in NuttX repo
> it should be splitted between nuttx and apps-repos and use POSIX
> implementation as much as possible. We are focused on standards and
> compatibility.
>
> Another concern is the license which does not match our ASF one and does
> not include any LICENSE file additions to clarify the compiance aspect
>
> Best regards
> Alin J
>
> On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com> wrote:
>
> > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> >
> > > So the real reason you've been objecting to my proposal is that your
> team
> > > has been working on something similar, correct?
> > >
> > > If you can give me a clear timeline for when your implementation will
> be
> > > submitted upstream, I'm happy to withdraw my PR and let your code serve
> > as
> > > the baseline. I'm not here to fight over ownership of the Bluetooth
> > stack.
> > > My only motivation is that NuttX's lack of a capable Bluetooth stack is
> > > driving every developer toward Zephyr — and as a PMC member, I think
> you
> > > should be asking yourselves why this gap has remained unfilled for so
> > long.
> > >
> > >
> > I object to landing the whole bluetooth stack into kernel space directly
> > either yours and ours .
> > This is the same feeling from raiden00pl too, let's see other people's
> > opinions here.
> > But it's fine for me to host the whole code in nuttx-apps.git and
> refactor
> > components to kernel
> > space step by step.
> >
> >
> > > As for the current PR, I'll remove the shell components from the stack
> > and
> > > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> > will
> > > stay in libc —
> >
> >
> > The architecture is wrong to host any bluetooth profile in libc.
> >
> > in flat build mode this gives a significant performance
> > > boost to the overall stack, which is the primary deployment model for
> > most
> > > NuttX devices.
> > >
> > >
> > Performance should remain the same whether the base profile is hosted in
> > libc or apps,
> > could you point out any technical reason which impacts the performance in
> > the flat mode?
> >
> >
> > > A few additional data points regarding our timeline: our product is
> > > scheduled for release in December, and Bluetooth SIG certification is
> > > already in progress — we expect to receive it around November. If the
> > > baseline were to switch to your team's stack with its different
> > > architecture, that certification cycle would need to be repeated, which
> > is
> > > not trivial given the time and cost involved.
> > >
> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > >
> > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> > > >
> > > > > Hi raiden00pl,
> > > > >
> > > > > Regarding your point about the NimBLE port using the POSIX API —
> yes,
> > > it
> > > > > uses POSIX, but there are real issues with the current
> implementation
> > > > that
> > > > > go beyond just kernel/protected mode support.
> > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > >
> > > > > Look at the NuttX port's implementation:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > > >
> > > > > static pthread_mutex_t s_mutex =
> > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > >
> > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > {
> > > > > pthread_mutex_lock(&s_mutex);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > This is a mutex, not a critical section. It does not disable
> > interrupts
> > > > or
> > > > > preemption — an ISR can still fire and corrupt data that the
> > "critical
> > > > > section" was supposed to protect. On top of that, using a mutex
> opens
> > > the
> > > > > door to ABBA deadlocks when combined with any other lock held
> inside
> > > the
> > > > > critical region:
> > > > >
> > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > > > blocked
> > > > > by B
> > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked
> by
> > A
> > > > >
> > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> disabling
> > > > > scheduling/preemption). The current NuttX port simply does not meet
> > the
> > > > > semantic contract that the NimBLE stack expects from
> > > > > ble_npl_hw_enter_critical.
> > > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > > >
> > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC,
> ...),
> > > > which
> > > > > involves a syscall and floating-point arithmetic on every call. In
> a
> > > BLE
> > > > > stack where timestamps and timing are on the hot path, this adds
> > > > measurable
> > > > > overhead compared to accessing the kernel tick counter directly.
> > > > > 3. Others are already using the kernel approach — and for good
> reason
> > > > >
> > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > openvela/NuttX
> > > > > uses kernel APIs directly, bypassing POSIX for the
> > performance-critical
> > > > > paths:
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > >
> > > > > This isn't an academic exercise — it's a production choice. They
> > > > recognized
> > > > > that a BLE stack needs tight integration with the OS timer
> subsystem,
> > > > > direct access to critical section primitives, and efficient event
> > > > delivery,
> > > > > none of which POSIX provides well in this context.
> > > > > My question
> > > > >
> > > > > If other organizations are already using a more performant,
> > > > architecturally
> > > > > correct kernel-level integration for their BLE stacks on NuttX, why
> > > > should
> > > > > we be told that we must use the slower, less correct POSIX path?
> > > NuttX's
> > > > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > > > shipping
> > > > > a BLE stack with a broken critical section primitive. There should
> be
> > > > room
> > > > > for both approaches, and the decision should be driven by technical
> > > > merit,
> > > > > not by treating POSIX as the only acceptable answer.
> > > > >
> > > > >
> > > > I don't object to moving the key bluetooth stack to kernel space like
> > how
> > > > the current bluetooth stack is done,
> > > > what I object to is that the current state of
> > > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > > into kernel space.
> > > > If I low my quality bar, I have requested my teammate to upstream our
> > > > implementation:
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > since much work needs to be done before it can achieve the quality
> > > > upstream.
> > > > BTW, many zephyr class BT features are developed by my team and
> > upstream
> > > to
> > > > Zeprhy community.
> > > > If considering the quality, our version is much better since:
> > > >
> > > > 1. Product on smart speaker last year
> > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > 3. Product on wear device by end of this year
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Alin Jerpelea <je...@gmail.com>.
Hi,
thanks Xiao and Raiden for your technical opinions which I also share so I
will not iterate them again.
I am against merging this pr in NuttX repo
it should be splitted between nuttx and apps-repos and use POSIX
implementation as much as possible. We are focused on standards and
compatibility.
Another concern is the license which does not match our ASF one and does
not include any LICENSE file additions to clarify the compiance aspect
Best regards
Alin J
On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <xi...@gmail.com> wrote:
> On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
>
> > So the real reason you've been objecting to my proposal is that your team
> > has been working on something similar, correct?
> >
> > If you can give me a clear timeline for when your implementation will be
> > submitted upstream, I'm happy to withdraw my PR and let your code serve
> as
> > the baseline. I'm not here to fight over ownership of the Bluetooth
> stack.
> > My only motivation is that NuttX's lack of a capable Bluetooth stack is
> > driving every developer toward Zephyr — and as a PMC member, I think you
> > should be asking yourselves why this gap has remained unfilled for so
> long.
> >
> >
> I object to landing the whole bluetooth stack into kernel space directly
> either yours and ours .
> This is the same feeling from raiden00pl too, let's see other people's
> opinions here.
> But it's fine for me to host the whole code in nuttx-apps.git and refactor
> components to kernel
> space step by step.
>
>
> > As for the current PR, I'll remove the shell components from the stack
> and
> > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> will
> > stay in libc —
>
>
> The architecture is wrong to host any bluetooth profile in libc.
>
> in flat build mode this gives a significant performance
> > boost to the overall stack, which is the primary deployment model for
> most
> > NuttX devices.
> >
> >
> Performance should remain the same whether the base profile is hosted in
> libc or apps,
> could you point out any technical reason which impacts the performance in
> the flat mode?
>
>
> > A few additional data points regarding our timeline: our product is
> > scheduled for release in December, and Bluetooth SIG certification is
> > already in progress — we expect to receive it around November. If the
> > baseline were to switch to your team's stack with its different
> > architecture, that certification cycle would need to be repeated, which
> is
> > not trivial given the time and cost involved.
> >
> > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> >
> > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi raiden00pl,
> > > >
> > > > Regarding your point about the NimBLE port using the POSIX API — yes,
> > it
> > > > uses POSIX, but there are real issues with the current implementation
> > > that
> > > > go beyond just kernel/protected mode support.
> > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > >
> > > > Look at the NuttX port's implementation:
> > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > >
> > > > static pthread_mutex_t s_mutex =
> > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > >
> > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > {
> > > > pthread_mutex_lock(&s_mutex);
> > > > return 0;
> > > > }
> > > >
> > > > This is a mutex, not a critical section. It does not disable
> interrupts
> > > or
> > > > preemption — an ISR can still fire and corrupt data that the
> "critical
> > > > section" was supposed to protect. On top of that, using a mutex opens
> > the
> > > > door to ABBA deadlocks when combined with any other lock held inside
> > the
> > > > critical region:
> > > >
> > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > > blocked
> > > > by B
> > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by
> A
> > > >
> > > > Compare this with the FreeRTOS port, which correctly uses
> > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > > scheduling/preemption). The current NuttX port simply does not meet
> the
> > > > semantic contract that the NimBLE stack expects from
> > > > ble_npl_hw_enter_critical.
> > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > >
> > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > > which
> > > > involves a syscall and floating-point arithmetic on every call. In a
> > BLE
> > > > stack where timestamps and timing are on the hot path, this adds
> > > measurable
> > > > overhead compared to accessing the kernel tick counter directly.
> > > > 3. Others are already using the kernel approach — and for good reason
> > > >
> > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> openvela/NuttX
> > > > uses kernel APIs directly, bypassing POSIX for the
> performance-critical
> > > > paths:
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > >
> > > > This isn't an academic exercise — it's a production choice. They
> > > recognized
> > > > that a BLE stack needs tight integration with the OS timer subsystem,
> > > > direct access to critical section primitives, and efficient event
> > > delivery,
> > > > none of which POSIX provides well in this context.
> > > > My question
> > > >
> > > > If other organizations are already using a more performant,
> > > architecturally
> > > > correct kernel-level integration for their BLE stacks on NuttX, why
> > > should
> > > > we be told that we must use the slower, less correct POSIX path?
> > NuttX's
> > > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > > shipping
> > > > a BLE stack with a broken critical section primitive. There should be
> > > room
> > > > for both approaches, and the decision should be driven by technical
> > > merit,
> > > > not by treating POSIX as the only acceptable answer.
> > > >
> > > >
> > > I don't object to moving the key bluetooth stack to kernel space like
> how
> > > the current bluetooth stack is done,
> > > what I object to is that the current state of
> > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > into kernel space.
> > > If I low my quality bar, I have requested my teammate to upstream our
> > > implementation:
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > since much work needs to be done before it can achieve the quality
> > > upstream.
> > > BTW, many zephyr class BT features are developed by my team and
> upstream
> > to
> > > Zeprhy community.
> > > If considering the quality, our version is much better since:
> > >
> > > 1. Product on smart speaker last year
> > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > 3. Product on wear device by end of this year
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi Alin,
Appreciate the clarification, and thanks for engaging constructively. I
fully agree that the code needs to meet NuttX's standards — that's what the
review process is for. I'll work on addressing the concerns raised so far
(POSIX API layering, proper repo split between nuttx/ and apps/, and
license compliance) as the discussion on the final architecture converges.
Alin Jerpelea <je...@gmail.com> 于2026年10月16日周五 17:14写道：
> Hi Chao an,
>
> thanks for sharing your thoughts
>
> I would like to clarify that I am not against your work but I would like to
> see it evolve so that it follows the NuttX requirements
>
> Thanks
> Alin J
>
> On Fri, 16 Oct 2026, 10:55 chao an, <ma...@gmail.com> wrote:
>
> > The performance difference comes from the OS abstraction layer we plan to
> > implement. Here's the design:
> >
> > The profile code will sit in libc, but the system API isolation layer
> > beneath it will provide two backends: a POSIX-compatible backend and a
> > kernel-native backend. When building in flat mode, the isolation layer
> > switches to the kernel API path — direct calls into the kernel without
> > going through the POSIX syscall layer. For low-performance IoT chips,
> > eliminating that overhead on every timer operation, mutex acquisition,
> and
> > event delivery is a significant win.
> >
> > If we were to place the profiles in apps/ instead, we'd be in an awkward
> > position: the code in apps/ would need to call kernel APIs directly in
> flat
> > mode to achieve the same performance, which breaks the convention that
> > apps/ code should be pure POSIX. The architectural boundary should be
> clean
> > — kernel APIs belong in the kernel or libc, and apps/ stays POSIX-only.
> > Putting the profile code in libc keeps that boundary intact while still
> > allowing the flat-mode optimization path.
> >
> > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 16:12写道：
> >
> > > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> > >
> > > > So the real reason you've been objecting to my proposal is that your
> > team
> > > > has been working on something similar, correct?
> > > >
> > > > If you can give me a clear timeline for when your implementation will
> > be
> > > > submitted upstream, I'm happy to withdraw my PR and let your code
> serve
> > > as
> > > > the baseline. I'm not here to fight over ownership of the Bluetooth
> > > stack.
> > > > My only motivation is that NuttX's lack of a capable Bluetooth stack
> is
> > > > driving every developer toward Zephyr — and as a PMC member, I think
> > you
> > > > should be asking yourselves why this gap has remained unfilled for so
> > > long.
> > > >
> > > >
> > > I object to landing the whole bluetooth stack into kernel space
> directly
> > > either yours and ours .
> > > This is the same feeling from raiden00pl too, let's see other people's
> > > opinions here.
> > > But it's fine for me to host the whole code in nuttx-apps.git and
> > refactor
> > > components to kernel
> > > space step by step.
> > >
> > >
> > > > As for the current PR, I'll remove the shell components from the
> stack
> > > and
> > > > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> > > will
> > > > stay in libc —
> > >
> > >
> > > The architecture is wrong to host any bluetooth profile in libc.
> > >
> > > in flat build mode this gives a significant performance
> > > > boost to the overall stack, which is the primary deployment model for
> > > most
> > > > NuttX devices.
> > > >
> > > >
> > > Performance should remain the same whether the base profile is hosted
> in
> > > libc or apps,
> > > could you point out any technical reason which impacts the performance
> in
> > > the flat mode?
> > >
> > >
> > > > A few additional data points regarding our timeline: our product is
> > > > scheduled for release in December, and Bluetooth SIG certification is
> > > > already in progress — we expect to receive it around November. If the
> > > > baseline were to switch to your team's stack with its different
> > > > architecture, that certification cycle would need to be repeated,
> which
> > > is
> > > > not trivial given the time and cost involved.
> > > >
> > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > > >
> > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com>
> wrote:
> > > > >
> > > > > > Hi raiden00pl,
> > > > > >
> > > > > > Regarding your point about the NimBLE port using the POSIX API —
> > yes,
> > > > it
> > > > > > uses POSIX, but there are real issues with the current
> > implementation
> > > > > that
> > > > > > go beyond just kernel/protected mode support.
> > > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > > >
> > > > > > Look at the NuttX port's implementation:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > > > >
> > > > > > static pthread_mutex_t s_mutex =
> > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > >
> > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > {
> > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > This is a mutex, not a critical section. It does not disable
> > > interrupts
> > > > > or
> > > > > > preemption — an ISR can still fire and corrupt data that the
> > > "critical
> > > > > > section" was supposed to protect. On top of that, using a mutex
> > opens
> > > > the
> > > > > > door to ABBA deadlocks when combined with any other lock held
> > inside
> > > > the
> > > > > > critical region:
> > > > > >
> > > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex
> M) ←
> > > > > blocked
> > > > > > by B
> > > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked
> > by
> > > A
> > > > > >
> > > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> > disabling
> > > > > > scheduling/preemption). The current NuttX port simply does not
> meet
> > > the
> > > > > > semantic contract that the NimBLE stack expects from
> > > > > > ble_npl_hw_enter_critical.
> > > > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > > > >
> > > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC,
> > ...),
> > > > > which
> > > > > > involves a syscall and floating-point arithmetic on every call.
> In
> > a
> > > > BLE
> > > > > > stack where timestamps and timing are on the hot path, this adds
> > > > > measurable
> > > > > > overhead compared to accessing the kernel tick counter directly.
> > > > > > 3. Others are already using the kernel approach — and for good
> > reason
> > > > > >
> > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > > openvela/NuttX
> > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > performance-critical
> > > > > > paths:
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > >
> > > > > > This isn't an academic exercise — it's a production choice. They
> > > > > recognized
> > > > > > that a BLE stack needs tight integration with the OS timer
> > subsystem,
> > > > > > direct access to critical section primitives, and efficient event
> > > > > delivery,
> > > > > > none of which POSIX provides well in this context.
> > > > > > My question
> > > > > >
> > > > > > If other organizations are already using a more performant,
> > > > > architecturally
> > > > > > correct kernel-level integration for their BLE stacks on NuttX,
> why
> > > > > should
> > > > > > we be told that we must use the slower, less correct POSIX path?
> > > > NuttX's
> > > > > > POSIX compliance is valuable, but it shouldn't come at the cost
> of
> > > > > shipping
> > > > > > a BLE stack with a broken critical section primitive. There
> should
> > be
> > > > > room
> > > > > > for both approaches, and the decision should be driven by
> technical
> > > > > merit,
> > > > > > not by treating POSIX as the only acceptable answer.
> > > > > >
> > > > > >
> > > > > I don't object to moving the key bluetooth stack to kernel space
> like
> > > how
> > > > > the current bluetooth stack is done,
> > > > > what I object to is that the current state of
> > > > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > > > into kernel space.
> > > > > If I low my quality bar, I have requested my teammate to upstream
> our
> > > > > implementation:
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > since much work needs to be done before it can achieve the quality
> > > > > upstream.
> > > > > BTW, many zephyr class BT features are developed by my team and
> > > upstream
> > > > to
> > > > > Zeprhy community.
> > > > > If considering the quality, our version is much better since:
> > > > >
> > > > > 1. Product on smart speaker last year
> > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > > 3. Product on wear device by end of this year
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Alin Jerpelea <je...@gmail.com>.
Hi Chao an,
thanks for sharing your thoughts
I would like to clarify that I am not against your work but I would like to
see it evolve so that it follows the NuttX requirements
Thanks
Alin J
On Fri, 16 Oct 2026, 10:55 chao an, <ma...@gmail.com> wrote:
> The performance difference comes from the OS abstraction layer we plan to
> implement. Here's the design:
>
> The profile code will sit in libc, but the system API isolation layer
> beneath it will provide two backends: a POSIX-compatible backend and a
> kernel-native backend. When building in flat mode, the isolation layer
> switches to the kernel API path — direct calls into the kernel without
> going through the POSIX syscall layer. For low-performance IoT chips,
> eliminating that overhead on every timer operation, mutex acquisition, and
> event delivery is a significant win.
>
> If we were to place the profiles in apps/ instead, we'd be in an awkward
> position: the code in apps/ would need to call kernel APIs directly in flat
> mode to achieve the same performance, which breaks the convention that
> apps/ code should be pure POSIX. The architectural boundary should be clean
> — kernel APIs belong in the kernel or libc, and apps/ stays POSIX-only.
> Putting the profile code in libc keeps that boundary intact while still
> allowing the flat-mode optimization path.
>
> Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 16:12写道：
>
> > On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> >
> > > So the real reason you've been objecting to my proposal is that your
> team
> > > has been working on something similar, correct?
> > >
> > > If you can give me a clear timeline for when your implementation will
> be
> > > submitted upstream, I'm happy to withdraw my PR and let your code serve
> > as
> > > the baseline. I'm not here to fight over ownership of the Bluetooth
> > stack.
> > > My only motivation is that NuttX's lack of a capable Bluetooth stack is
> > > driving every developer toward Zephyr — and as a PMC member, I think
> you
> > > should be asking yourselves why this gap has remained unfilled for so
> > long.
> > >
> > >
> > I object to landing the whole bluetooth stack into kernel space directly
> > either yours and ours .
> > This is the same feeling from raiden00pl too, let's see other people's
> > opinions here.
> > But it's fine for me to host the whole code in nuttx-apps.git and
> refactor
> > components to kernel
> > space step by step.
> >
> >
> > > As for the current PR, I'll remove the shell components from the stack
> > and
> > > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> > will
> > > stay in libc —
> >
> >
> > The architecture is wrong to host any bluetooth profile in libc.
> >
> > in flat build mode this gives a significant performance
> > > boost to the overall stack, which is the primary deployment model for
> > most
> > > NuttX devices.
> > >
> > >
> > Performance should remain the same whether the base profile is hosted in
> > libc or apps,
> > could you point out any technical reason which impacts the performance in
> > the flat mode?
> >
> >
> > > A few additional data points regarding our timeline: our product is
> > > scheduled for release in December, and Bluetooth SIG certification is
> > > already in progress — we expect to receive it around November. If the
> > > baseline were to switch to your team's stack with its different
> > > architecture, that certification cycle would need to be repeated, which
> > is
> > > not trivial given the time and cost involved.
> > >
> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> > >
> > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> > > >
> > > > > Hi raiden00pl,
> > > > >
> > > > > Regarding your point about the NimBLE port using the POSIX API —
> yes,
> > > it
> > > > > uses POSIX, but there are real issues with the current
> implementation
> > > > that
> > > > > go beyond just kernel/protected mode support.
> > > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > > >
> > > > > Look at the NuttX port's implementation:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > > >
> > > > > static pthread_mutex_t s_mutex =
> > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > >
> > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > {
> > > > > pthread_mutex_lock(&s_mutex);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > This is a mutex, not a critical section. It does not disable
> > interrupts
> > > > or
> > > > > preemption — an ISR can still fire and corrupt data that the
> > "critical
> > > > > section" was supposed to protect. On top of that, using a mutex
> opens
> > > the
> > > > > door to ABBA deadlocks when combined with any other lock held
> inside
> > > the
> > > > > critical region:
> > > > >
> > > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > > > blocked
> > > > > by B
> > > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked
> by
> > A
> > > > >
> > > > > Compare this with the FreeRTOS port, which correctly uses
> > > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually
> disabling
> > > > > scheduling/preemption). The current NuttX port simply does not meet
> > the
> > > > > semantic contract that the NimBLE stack expects from
> > > > > ble_npl_hw_enter_critical.
> > > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > > >
> > > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC,
> ...),
> > > > which
> > > > > involves a syscall and floating-point arithmetic on every call. In
> a
> > > BLE
> > > > > stack where timestamps and timing are on the hot path, this adds
> > > > measurable
> > > > > overhead compared to accessing the kernel tick counter directly.
> > > > > 3. Others are already using the kernel approach — and for good
> reason
> > > > >
> > > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > openvela/NuttX
> > > > > uses kernel APIs directly, bypassing POSIX for the
> > performance-critical
> > > > > paths:
> > > > >
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > >
> > > > > This isn't an academic exercise — it's a production choice. They
> > > > recognized
> > > > > that a BLE stack needs tight integration with the OS timer
> subsystem,
> > > > > direct access to critical section primitives, and efficient event
> > > > delivery,
> > > > > none of which POSIX provides well in this context.
> > > > > My question
> > > > >
> > > > > If other organizations are already using a more performant,
> > > > architecturally
> > > > > correct kernel-level integration for their BLE stacks on NuttX, why
> > > > should
> > > > > we be told that we must use the slower, less correct POSIX path?
> > > NuttX's
> > > > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > > > shipping
> > > > > a BLE stack with a broken critical section primitive. There should
> be
> > > > room
> > > > > for both approaches, and the decision should be driven by technical
> > > > merit,
> > > > > not by treating POSIX as the only acceptable answer.
> > > > >
> > > > >
> > > > I don't object to moving the key bluetooth stack to kernel space like
> > how
> > > > the current bluetooth stack is done,
> > > > what I object to is that the current state of
> > > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > > into kernel space.
> > > > If I low my quality bar, I have requested my teammate to upstream our
> > > > implementation:
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > since much work needs to be done before it can achieve the quality
> > > > upstream.
> > > > BTW, many zephyr class BT features are developed by my team and
> > upstream
> > > to
> > > > Zeprhy community.
> > > > If considering the quality, our version is much better since:
> > > >
> > > > 1. Product on smart speaker last year
> > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > > 3. Product on wear device by end of this year
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
The performance difference comes from the OS abstraction layer we plan to
implement. Here's the design:
The profile code will sit in libc, but the system API isolation layer
beneath it will provide two backends: a POSIX-compatible backend and a
kernel-native backend. When building in flat mode, the isolation layer
switches to the kernel API path — direct calls into the kernel without
going through the POSIX syscall layer. For low-performance IoT chips,
eliminating that overhead on every timer operation, mutex acquisition, and
event delivery is a significant win.
If we were to place the profiles in apps/ instead, we'd be in an awkward
position: the code in apps/ would need to call kernel APIs directly in flat
mode to achieve the same performance, which breaks the convention that
apps/ code should be pure POSIX. The architectural boundary should be clean
— kernel APIs belong in the kernel or libc, and apps/ stays POSIX-only.
Putting the profile code in libc keeps that boundary intact while still
allowing the flat-mode optimization path.
Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 16:12写道：
> On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
>
> > So the real reason you've been objecting to my proposal is that your team
> > has been working on something similar, correct?
> >
> > If you can give me a clear timeline for when your implementation will be
> > submitted upstream, I'm happy to withdraw my PR and let your code serve
> as
> > the baseline. I'm not here to fight over ownership of the Bluetooth
> stack.
> > My only motivation is that NuttX's lack of a capable Bluetooth stack is
> > driving every developer toward Zephyr — and as a PMC member, I think you
> > should be asking yourselves why this gap has remained unfilled for so
> long.
> >
> >
> I object to landing the whole bluetooth stack into kernel space directly
> either yours and ours .
> This is the same feeling from raiden00pl too, let's see other people's
> opinions here.
> But it's fine for me to host the whole code in nuttx-apps.git and refactor
> components to kernel
> space step by step.
>
>
> > As for the current PR, I'll remove the shell components from the stack
> and
> > move them into apps/ where they belong. The base profiles (A2DP, BLE)
> will
> > stay in libc —
>
>
> The architecture is wrong to host any bluetooth profile in libc.
>
> in flat build mode this gives a significant performance
> > boost to the overall stack, which is the primary deployment model for
> most
> > NuttX devices.
> >
> >
> Performance should remain the same whether the base profile is hosted in
> libc or apps,
> could you point out any technical reason which impacts the performance in
> the flat mode?
>
>
> > A few additional data points regarding our timeline: our product is
> > scheduled for release in December, and Bluetooth SIG certification is
> > already in progress — we expect to receive it around November. If the
> > baseline were to switch to your team's stack with its different
> > architecture, that certification cycle would need to be repeated, which
> is
> > not trivial given the time and cost involved.
> >
> > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> >
> > > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi raiden00pl,
> > > >
> > > > Regarding your point about the NimBLE port using the POSIX API — yes,
> > it
> > > > uses POSIX, but there are real issues with the current implementation
> > > that
> > > > go beyond just kernel/protected mode support.
> > > > 1. ble_npl_hw_enter_critical is not a real critical section
> > > >
> > > > Look at the NuttX port's implementation:
> > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > >
> > > > static pthread_mutex_t s_mutex =
> > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > >
> > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > {
> > > > pthread_mutex_lock(&s_mutex);
> > > > return 0;
> > > > }
> > > >
> > > > This is a mutex, not a critical section. It does not disable
> interrupts
> > > or
> > > > preemption — an ISR can still fire and corrupt data that the
> "critical
> > > > section" was supposed to protect. On top of that, using a mutex opens
> > the
> > > > door to ABBA deadlocks when combined with any other lock held inside
> > the
> > > > critical region:
> > > >
> > > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > > blocked
> > > > by B
> > > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by
> A
> > > >
> > > > Compare this with the FreeRTOS port, which correctly uses
> > > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > > scheduling/preemption). The current NuttX port simply does not meet
> the
> > > > semantic contract that the NimBLE stack expects from
> > > > ble_npl_hw_enter_critical.
> > > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > >
> > > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > > which
> > > > involves a syscall and floating-point arithmetic on every call. In a
> > BLE
> > > > stack where timestamps and timing are on the hot path, this adds
> > > measurable
> > > > overhead compared to accessing the kernel tick counter directly.
> > > > 3. Others are already using the kernel approach — and for good reason
> > > >
> > > > A concrete example: Xiaomi's Bluetooth stack (zblue) for
> openvela/NuttX
> > > > uses kernel APIs directly, bypassing POSIX for the
> performance-critical
> > > > paths:
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > >
> > > > This isn't an academic exercise — it's a production choice. They
> > > recognized
> > > > that a BLE stack needs tight integration with the OS timer subsystem,
> > > > direct access to critical section primitives, and efficient event
> > > delivery,
> > > > none of which POSIX provides well in this context.
> > > > My question
> > > >
> > > > If other organizations are already using a more performant,
> > > architecturally
> > > > correct kernel-level integration for their BLE stacks on NuttX, why
> > > should
> > > > we be told that we must use the slower, less correct POSIX path?
> > NuttX's
> > > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > > shipping
> > > > a BLE stack with a broken critical section primitive. There should be
> > > room
> > > > for both approaches, and the decision should be driven by technical
> > > merit,
> > > > not by treating POSIX as the only acceptable answer.
> > > >
> > > >
> > > I don't object to moving the key bluetooth stack to kernel space like
> how
> > > the current bluetooth stack is done,
> > > what I object to is that the current state of
> > > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > > into kernel space.
> > > If I low my quality bar, I have requested my teammate to upstream our
> > > implementation:
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > since much work needs to be done before it can achieve the quality
> > > upstream.
> > > BTW, many zephyr class BT features are developed by my team and
> upstream
> > to
> > > Zeprhy community.
> > > If considering the quality, our version is much better since:
> > >
> > > 1. Product on smart speaker last year
> > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > > 3. Product on wear device by end of this year
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Oct 16, 2026 at 3:49 PM chao an <ma...@gmail.com> wrote:
> So the real reason you've been objecting to my proposal is that your team
> has been working on something similar, correct?
>
> If you can give me a clear timeline for when your implementation will be
> submitted upstream, I'm happy to withdraw my PR and let your code serve as
> the baseline. I'm not here to fight over ownership of the Bluetooth stack.
> My only motivation is that NuttX's lack of a capable Bluetooth stack is
> driving every developer toward Zephyr — and as a PMC member, I think you
> should be asking yourselves why this gap has remained unfilled for so long.
>
>
I object to landing the whole bluetooth stack into kernel space directly
either yours and ours .
This is the same feeling from raiden00pl too, let's see other people's
opinions here.
But it's fine for me to host the whole code in nuttx-apps.git and refactor
components to kernel
space step by step.
> As for the current PR, I'll remove the shell components from the stack and
> move them into apps/ where they belong. The base profiles (A2DP, BLE) will
> stay in libc —
The architecture is wrong to host any bluetooth profile in libc.
in flat build mode this gives a significant performance
> boost to the overall stack, which is the primary deployment model for most
> NuttX devices.
>
>
Performance should remain the same whether the base profile is hosted in
libc or apps,
could you point out any technical reason which impacts the performance in
the flat mode?
> A few additional data points regarding our timeline: our product is
> scheduled for release in December, and Bluetooth SIG certification is
> already in progress — we expect to receive it around November. If the
> baseline were to switch to your team's stack with its different
> architecture, that certification cycle would need to be repeated, which is
> not trivial given the time and cost involved.
>
> Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
>
> > On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> >
> > > Hi raiden00pl,
> > >
> > > Regarding your point about the NimBLE port using the POSIX API — yes,
> it
> > > uses POSIX, but there are real issues with the current implementation
> > that
> > > go beyond just kernel/protected mode support.
> > > 1. ble_npl_hw_enter_critical is not a real critical section
> > >
> > > Look at the NuttX port's implementation:
> > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > >
> > > static pthread_mutex_t s_mutex =
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > >
> > > uint32_t ble_npl_hw_enter_critical(void)
> > > {
> > > pthread_mutex_lock(&s_mutex);
> > > return 0;
> > > }
> > >
> > > This is a mutex, not a critical section. It does not disable interrupts
> > or
> > > preemption — an ISR can still fire and corrupt data that the "critical
> > > section" was supposed to protect. On top of that, using a mutex opens
> the
> > > door to ABBA deadlocks when combined with any other lock held inside
> the
> > > critical region:
> > >
> > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > blocked
> > > by B
> > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> > >
> > > Compare this with the FreeRTOS port, which correctly uses
> > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > scheduling/preemption). The current NuttX port simply does not meet the
> > > semantic contract that the NimBLE stack expects from
> > > ble_npl_hw_enter_critical.
> > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > >
> > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > >
> > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > which
> > > involves a syscall and floating-point arithmetic on every call. In a
> BLE
> > > stack where timestamps and timing are on the hot path, this adds
> > measurable
> > > overhead compared to accessing the kernel tick counter directly.
> > > 3. Others are already using the kernel approach — and for good reason
> > >
> > > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> > > uses kernel APIs directly, bypassing POSIX for the performance-critical
> > > paths:
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > >
> > > This isn't an academic exercise — it's a production choice. They
> > recognized
> > > that a BLE stack needs tight integration with the OS timer subsystem,
> > > direct access to critical section primitives, and efficient event
> > delivery,
> > > none of which POSIX provides well in this context.
> > > My question
> > >
> > > If other organizations are already using a more performant,
> > architecturally
> > > correct kernel-level integration for their BLE stacks on NuttX, why
> > should
> > > we be told that we must use the slower, less correct POSIX path?
> NuttX's
> > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > shipping
> > > a BLE stack with a broken critical section primitive. There should be
> > room
> > > for both approaches, and the decision should be driven by technical
> > merit,
> > > not by treating POSIX as the only acceptable answer.
> > >
> > >
> > I don't object to moving the key bluetooth stack to kernel space like how
> > the current bluetooth stack is done,
> > what I object to is that the current state of
> > https://github.com/apache/nuttx/pull/20686 is far to move entirely
> > into kernel space.
> > If I low my quality bar, I have requested my teammate to upstream our
> > implementation:
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > since much work needs to be done before it can achieve the quality
> > upstream.
> > BTW, many zephyr class BT features are developed by my team and upstream
> to
> > Zeprhy community.
> > If considering the quality, our version is much better since:
> >
> > 1. Product on smart speaker last year
> > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> > 3. Product on wear device by end of this year
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
So the real reason you've been objecting to my proposal is that your team
has been working on something similar, correct?
If you can give me a clear timeline for when your implementation will be
submitted upstream, I'm happy to withdraw my PR and let your code serve as
the baseline. I'm not here to fight over ownership of the Bluetooth stack.
My only motivation is that NuttX's lack of a capable Bluetooth stack is
driving every developer toward Zephyr — and as a PMC member, I think you
should be asking yourselves why this gap has remained unfilled for so long.
As for the current PR, I'll remove the shell components from the stack and
move them into apps/ where they belong. The base profiles (A2DP, BLE) will
stay in libc — in flat build mode this gives a significant performance
boost to the overall stack, which is the primary deployment model for most
NuttX devices.
A few additional data points regarding our timeline: our product is
scheduled for release in December, and Bluetooth SIG certification is
already in progress — we expect to receive it around November. If the
baseline were to switch to your team's stack with its different
architecture, that certification cycle would need to be repeated, which is
not trivial given the time and cost involved.
Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 15:08写道：
> On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
>
> > Hi raiden00pl,
> >
> > Regarding your point about the NimBLE port using the POSIX API — yes, it
> > uses POSIX, but there are real issues with the current implementation
> that
> > go beyond just kernel/protected mode support.
> > 1. ble_npl_hw_enter_critical is not a real critical section
> >
> > Look at the NuttX port's implementation:
> >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> >
> > static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> >
> > uint32_t ble_npl_hw_enter_critical(void)
> > {
> > pthread_mutex_lock(&s_mutex);
> > return 0;
> > }
> >
> > This is a mutex, not a critical section. It does not disable interrupts
> or
> > preemption — an ISR can still fire and corrupt data that the "critical
> > section" was supposed to protect. On top of that, using a mutex opens the
> > door to ABBA deadlocks when combined with any other lock held inside the
> > critical region:
> >
> > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> blocked
> > by B
> > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> >
> > Compare this with the FreeRTOS port, which correctly uses
> > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > scheduling/preemption). The current NuttX port simply does not meet the
> > semantic contract that the NimBLE stack expects from
> > ble_npl_hw_enter_critical.
> > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> >
> >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> >
> > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> which
> > involves a syscall and floating-point arithmetic on every call. In a BLE
> > stack where timestamps and timing are on the hot path, this adds
> measurable
> > overhead compared to accessing the kernel tick counter directly.
> > 3. Others are already using the kernel approach — and for good reason
> >
> > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> > uses kernel APIs directly, bypassing POSIX for the performance-critical
> > paths:
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> >
> > This isn't an academic exercise — it's a production choice. They
> recognized
> > that a BLE stack needs tight integration with the OS timer subsystem,
> > direct access to critical section primitives, and efficient event
> delivery,
> > none of which POSIX provides well in this context.
> > My question
> >
> > If other organizations are already using a more performant,
> architecturally
> > correct kernel-level integration for their BLE stacks on NuttX, why
> should
> > we be told that we must use the slower, less correct POSIX path? NuttX's
> > POSIX compliance is valuable, but it shouldn't come at the cost of
> shipping
> > a BLE stack with a broken critical section primitive. There should be
> room
> > for both approaches, and the decision should be driven by technical
> merit,
> > not by treating POSIX as the only acceptable answer.
> >
> >
> I don't object to moving the key bluetooth stack to kernel space like how
> the current bluetooth stack is done,
> what I object to is that the current state of
> https://github.com/apache/nuttx/pull/20686 is far to move entirely
> into kernel space.
> If I low my quality bar, I have requested my teammate to upstream our
> implementation:
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> since much work needs to be done before it can achieve the quality
> upstream.
> BTW, many zephyr class BT features are developed by my team and upstream to
> Zeprhy community.
> If considering the quality, our version is much better since:
>
> 1. Product on smart speaker last year
> 2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
> 3. Product on wear device by end of this year
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Oct 16, 2026 at 2:44 PM chao an <ma...@gmail.com> wrote:
> Hi raiden00pl,
>
> Regarding your point about the NimBLE port using the POSIX API — yes, it
> uses POSIX, but there are real issues with the current implementation that
> go beyond just kernel/protected mode support.
> 1. ble_npl_hw_enter_critical is not a real critical section
>
> Look at the NuttX port's implementation:
>
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
>
> static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>
> uint32_t ble_npl_hw_enter_critical(void)
> {
> pthread_mutex_lock(&s_mutex);
> return 0;
> }
>
> This is a mutex, not a critical section. It does not disable interrupts or
> preemption — an ISR can still fire and corrupt data that the "critical
> section" was supposed to protect. On top of that, using a mutex opens the
> door to ABBA deadlocks when combined with any other lock held inside the
> critical region:
>
> - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ← blocked
> by B
> - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
>
> Compare this with the FreeRTOS port, which correctly uses
> vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> scheduling/preemption). The current NuttX port simply does not meet the
> semantic contract that the NimBLE stack expects from
> ble_npl_hw_enter_critical.
> 2. Time subsystem uses clock_gettime instead of kernel tick APIs
>
>
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
>
> ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...), which
> involves a syscall and floating-point arithmetic on every call. In a BLE
> stack where timestamps and timing are on the hot path, this adds measurable
> overhead compared to accessing the kernel tick counter directly.
> 3. Others are already using the kernel approach — and for good reason
>
> A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> uses kernel APIs directly, bypassing POSIX for the performance-critical
> paths:
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
>
> This isn't an academic exercise — it's a production choice. They recognized
> that a BLE stack needs tight integration with the OS timer subsystem,
> direct access to critical section primitives, and efficient event delivery,
> none of which POSIX provides well in this context.
> My question
>
> If other organizations are already using a more performant, architecturally
> correct kernel-level integration for their BLE stacks on NuttX, why should
> we be told that we must use the slower, less correct POSIX path? NuttX's
> POSIX compliance is valuable, but it shouldn't come at the cost of shipping
> a BLE stack with a broken critical section primitive. There should be room
> for both approaches, and the decision should be driven by technical merit,
> not by treating POSIX as the only acceptable answer.
>
>
I don't object to moving the key bluetooth stack to kernel space like how
the current bluetooth stack is done,
what I object to is that the current state of
https://github.com/apache/nuttx/pull/20686 is far to move entirely
into kernel space.
If I low my quality bar, I have requested my teammate to upstream our
implementation:
https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
since much work needs to be done before it can achieve the quality upstream.
BTW, many zephyr class BT features are developed by my team and upstream to
Zeprhy community.
If considering the quality, our version is much better since:
1. Product on smart speaker last year
2. Pass Bluetooth SIG BT/BLE 6.2 certification at 2026.06
3. Product on wear device by end of this year
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Oct 16, 2026 at 3:06 PM chao an <ma...@gmail.com> wrote:
> I think there's a misunderstanding. Let me clarify the architecture once
> more, as this has been stated several times already in this thread:
>
> 1. L2CAP and below will live in the kernel. This is the same layering as
> the existing network stack — TCP/IP sits in the kernel, and that's not
> controversial. L2CAP is the BLE equivalent of the transport layer. It
> belongs there for the same reasons.
> 2. Higher-level profiles (GATT, GAP, etc.) will be moved to libc once
> the full stack integration is complete. They will use standard POSIX
> APIs
> and live in userspace, exactly as NuttX's architecture expects.
>
I don't agree with putting the bluetooth profile into libc, it must be
moved to nuttx-apps.git or separated git.
> 3. What you're seeing right now is Phase 1 only. This has been mentioned
> in the subject and in previous messages. It's an incremental merge —
> we're
> not dropping the entire BLE stack into the kernel and calling it done.
> The
> final architecture will respect NuttX's layering conventions: transport
> in
> the kernel, application-layer protocols in userspace/libc.
>
> This is fundamentally the same pattern NuttX already follows for IP
> networking. I'm not proposing anything that violates the project's
> architectural values.
>
>
Based on the current implementation, what I would prefer is to keep the
porting in nuttx-apps.git and
move the transport/driver layer to the kernel.
> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:56写道：
>
> > Your response has nothing to do with my reply to your comment about
> Nimble.
> > No one is claiming that the porting layer in Nimble is perfect, but it
> > certainly
> > doesn't use the kernel's private API.
> >
> > Good architecture and POSIX compliance are the core values of this
> project.
> > It has always been this way, and I hope it remains so. For this reason,
> > adding
> > anything to the kernel that sits above the L4–L5 layers of the OSI model
> is
> > a bad idea and I hope it never happens.
> >
> >
> > pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
> >
> > > Hi raiden00pl,
> > >
> > > Regarding your point about the NimBLE port using the POSIX API — yes,
> it
> > > uses POSIX, but there are real issues with the current implementation
> > that
> > > go beyond just kernel/protected mode support.
> > > 1. ble_npl_hw_enter_critical is not a real critical section
> > >
> > > Look at the NuttX port's implementation:
> > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > >
> > > static pthread_mutex_t s_mutex =
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > >
> > > uint32_t ble_npl_hw_enter_critical(void)
> > > {
> > > pthread_mutex_lock(&s_mutex);
> > > return 0;
> > > }
> > >
> > > This is a mutex, not a critical section. It does not disable interrupts
> > or
> > > preemption — an ISR can still fire and corrupt data that the "critical
> > > section" was supposed to protect. On top of that, using a mutex opens
> the
> > > door to ABBA deadlocks when combined with any other lock held inside
> the
> > > critical region:
> > >
> > > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > blocked
> > > by B
> > > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> > >
> > > Compare this with the FreeRTOS port, which correctly uses
> > > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > scheduling/preemption). The current NuttX port simply does not meet the
> > > semantic contract that the NimBLE stack expects from
> > > ble_npl_hw_enter_critical.
> > > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > >
> > >
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > >
> > > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > which
> > > involves a syscall and floating-point arithmetic on every call. In a
> BLE
> > > stack where timestamps and timing are on the hot path, this adds
> > measurable
> > > overhead compared to accessing the kernel tick counter directly.
> > > 3. Others are already using the kernel approach — and for good reason
> > >
> > > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> > > uses kernel APIs directly, bypassing POSIX for the performance-critical
> > > paths:
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > >
> > > This isn't an academic exercise — it's a production choice. They
> > recognized
> > > that a BLE stack needs tight integration with the OS timer subsystem,
> > > direct access to critical section primitives, and efficient event
> > delivery,
> > > none of which POSIX provides well in this context.
> > > My question
> > >
> > > If other organizations are already using a more performant,
> > architecturally
> > > correct kernel-level integration for their BLE stacks on NuttX, why
> > should
> > > we be told that we must use the slower, less correct POSIX path?
> NuttX's
> > > POSIX compliance is valuable, but it shouldn't come at the cost of
> > shipping
> > > a BLE stack with a broken critical section primitive. There should be
> > room
> > > for both approaches, and the decision should be driven by technical
> > merit,
> > > not by treating POSIX as the only acceptable answer.
> > >
> > > Best regards,
> > >
> > > raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
> > >
> > > > > We already have a similar problem with the current NimBLE
> > integration.
> > > > The
> > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > > kernel/internal
> > > > > APIs. As a result, it is difficult to support protected/kernel
> builds
> > > > > cleanly, and it is also hard to keep the port synchronized with
> > > upstream
> > > > > NimBLE over time.
> > > >
> > > > Is this an AI analysis or something? Because it’s definitely not
> true:
> > > > Nimble
> > > > port uses the POSIX API. The only issue with kernel mode is that
> > > > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> > > > limitation,
> > > > not a port architecture issue.
> > > > I agree that synchronizing with an external repository is a
> challenge.
> > > > However,
> > > > a plus side is that we aren't the ones maintaining the code that must
> > > > comply
> > > > with the BLE standard.
> > > >
> > > > I also consider placing the entire BLE stack within the kernel to be
> a
> > > bad
> > > > idea.
> > > > Even if performance isn't ideal, it’s the price one pays for a sound
> > > > architecture.
> > > > NuttX has always focused on addressing architectural challenges
> (POSIX
> > > > compliance)
> > > > rather than striving to be the best in terms of performance.
> > > >
> > > >
> > > > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
> > > >
> > > > > No, I do not agree that the current port is only a Zephyr API
> > > replacement
> > > > > and
> > > > > NuttX coding-style reformatting.
> > > > >
> > > > >
> > > > >
> > > > > This code base has already fixed part of the issues that still
> exist
> > in
> > > > the
> > > > >
> > > > > Zephyr community implementation. In addition, we still have pending
> > > > > features and
> > > > > fixes that have not been submitted yet. Since some of those changes
> > > were
> > > > > made by
> > > > > other developers, I cannot submit their work by myself without
> proper
> > > > > permission
> > > > > and attribution.
> > > > >
> > > > >
> > > > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> > > > >
> > > > >
> > > > > I have already stated in the email why I do not recommend putting
> the
> > > > > initial
> > > > > Bluetooth host stack into nuttx-apps. Architecturally, placing it
> in
> > > apps
> > > > > would
> > > > > cause significant performance degradation compared with the Zephyr
> > > > design.
> > > > > The
> > > > > Bluetooth host stack is tightly coupled with kernel primitives,
> > buffer
> > > > >
> > > > > management, work queues, timing, and HCI/driver paths. Moving it
> > > entirely
> > > > > to
> > > > > apps would change that integration model and make the architecture
> > > worse
> > > > > from
> > > > > the beginning.
> > > > >
> > > > >
> > > > >
> > > > > Therefore, please read my previous email more carefully. The
> concern
> > > here
> > > > > is not
> > > > > only the initial review size, but also the long-term architecture
> and
> > > > > runtime
> > > > > performance of the Bluetooth stack in NuttX.
> > > > >
> > > > > BRs,
> > > > >
> > > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> > > > >
> > > > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I would like to summarize the background, technical motivation,
> > and
> > > > > > > proposed evolution plan for PR #20686, which introduces a
> > > > Zephyr-based
> > > > > > > Bluetooth host stack under net/bt.
> > > > > > >
> > > > > > > https://github.com/apache/nuttx/pull/20686
> > > > > > >
> > > > > > > First of all, I fully understand the concerns raised in the
> > > > discussion.
> > > > > > > Adding a new Bluetooth stack is a significant architectural
> > change,
> > > > and
> > > > > > it
> > > > > > > is reasonable for the community to ask whether we should
> instead
> > > > > continue
> > > > > > > improving the existing NuttX Bluetooth implementation. I would
> > like
> > > > to
> > > > > > > explain why we believe introducing the new stack incrementally
> is
> > > the
> > > > > > more
> > > > > > > practical path, while still keeping the long-term NuttX
> > > architecture
> > > > > > clean
> > > > > > > and maintainable.
> > > > > > > ------------------------------
> > > > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > > > > > >
> > > > > > > The existing NuttX Bluetooth implementation is mainly focused
> on
> > > BLE
> > > > > > > functionality. However, modern Bluetooth support is no longer
> > > limited
> > > > > to
> > > > > > > basic BLE. A complete Bluetooth host stack now commonly
> includes:
> > > > > > >
> > > > > > > - BLE GAP/GATT/ATT/SMP
> > > > > > > - Classic Bluetooth profiles
> > > > > > > - A2DP
> > > > > > > - AVRCP
> > > > > > > - HFP/HSP
> > > > > > > - HID
> > > > > > > - LE Mesh
> > > > > > > - LE Audio
> > > > > > > - Additional profile-level interoperability logic
> > > > > > >
> > > > > > >
> > > > > > But most of these profiles should belong to the userspace, please
> > > split
> > > > > the
> > > > > > related code to nuttx-apps.git, instead nuttx/.
> > > > > > especially, the code related shell spread in the whole code base:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > > > > > it's definitely wrong to put the shell code inside kernel space.
> > > > > >
> > > > > >
> > > > > > > The Zephyr Bluetooth stack already provides a broad and
> actively
> > > > > > maintained
> > > > > > > implementation across many of these areas. Rebuilding
> equivalent
> > > > > > > functionality directly on top of the current NuttX Bluetooth
> > stack
> > > > > would
> > > > > > > require a very large multi-year effort, including not only
> > protocol
> > > > > > > implementation but also interoperability testing with real
> > phones,
> > > > > > > headsets, speakers, cars, and other commercial devices.
> > > > > > >
> > > > > > > Therefore, our goal is not to discard NuttX's existing work
> > > lightly,
> > > > > but
> > > > > > to
> > > > > > > provide a practical path to make NuttX capable of supporting a
> > much
> > > > > wider
> > > > > > > Bluetooth feature set in a reasonable time frame.
> > > > > > > ------------------------------
> > > > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > > > > > >
> > > > > > > Another important discussion point is whether the new Bluetooth
> > > stack
> > > > > > > should live in nuttx-apps, similar to how NimBLE is currently
> > > > > integrated.
> > > > > > >
> > > > > > > Our concern is that a host stack is not just an
> application-level
> > > > > > > component. It interacts closely with:
> > > > > > >
> > > > > > > - HCI transport
> > > > > > > - L2CAP channels
> > > > > > > - Socket or device interfaces
> > > > > > > - Memory pools
> > > > > > > - Timers and work queues
> > > > > > > - Security and pairing state
> > > > > > > - Profile registration
> > > > > > > - Controller event dispatch
> > > > > > > - Future kernel/user boundary mechanisms
> > > > > > >
> > > > > > > Putting the core host stack in nuttx-apps would either require
> > > > exposing
> > > > > > > many internal kernel interfaces or would force the
> > application-side
> > > > > stack
> > > > > > > to depend on non-public NuttX internals.
> > > > > > >
> > > > > > > We already have a similar problem with the current NimBLE
> > > > integration.
> > > > > > The
> > > > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > > > > kernel/internal
> > > > > > > APIs. As a result, it is difficult to support protected/kernel
> > > builds
> > > > > > > cleanly, and it is also hard to keep the port synchronized with
> > > > > upstream
> > > > > > > NimBLE over time.
> > > > > > >
> > > > > > >
> > > > > > These are kernel public API, the only problem is that they are
> > called
> > > > by
> > > > > > userspace.
> > > > > >
> > > > > >
> > > > > > > For this reason, we believe the Bluetooth host core belongs in
> > the
> > > > > NuttX
> > > > > > > tree. User-facing profiles, tools, shell commands, or demo
> > > > applications
> > > > > > can
> > > > > > > still live outside the core as appropriate, but the
> > > transport-facing
> > > > > host
> > > > > > > stack should have a well-defined place inside NuttX.
> > > > > > >
> > > > > > > There is also a performance consideration. In flat build mode,
> > the
> > > > > > > Bluetooth host stack can run directly on the kernel side
> without
> > > > > > additional
> > > > > > > syscall or user/kernel boundary overhead. This is especially
> > > > important
> > > > > > for
> > > > > > > IoT chips with relatively low CPU frequency, where Bluetooth
> data
> > > > path
> > > > > > and
> > > > > > > profile handling overhead can have a visible impact on
> > throughput,
> > > > > > latency,
> > > > > > > and power consumption.
> > > > > > >
> > > > > > > At the same time, this does not mean that the final
> architecture
> > > must
> > > > > > > remain flat-build-only. A compatible evolution path is to keep
> > the
> > > > > > > performance-sensitive transport and host core on the kernel
> side,
> > > > while
> > > > > > > gradually moving suitable Bluetooth profile implementations or
> > > > > > > profile-facing helper layers into libc-visible build paths.
> This
> > > > allows
> > > > > > > protected and kernel builds to use proper public interfaces,
> > while
> > > > > still
> > > > > > > preserving good performance for flat build and low-end IoT
> > > platforms.
> > > > > > >
> > > > > > > In other words, placing the stack in nuttx gives us a cleaner
> > > > long-term
> > > > > > > architecture:
> > > > > > >
> > > > > > > - Flat build can get the best performance with minimum
> > overhead.
> > > > > > > - Protected/kernel build can be supported later through
> proper
> > > > > public
> > > > > > > interfaces.
> > > > > > > - Profile code can be migrated into libc-compatible paths
> > where
> > > > > > > appropriate.
> > > > > > > - Userspace does not need to directly depend on private
> kernel
> > > > > > symbols.
> > > > > > > - The design avoids repeating the long-term maintainability
> > > issue
> > > > > seen
> > > > > > > in some existing userspace Bluetooth integrations.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > But Zephyr bluetooth stack is implemented as a monolithic block
> > like
> > > > > > NimBLE.
> > > > > > Your current porting just include:
> > > > > >
> > > > > > 1. Switch Zephyr API to NuttX kernel API
> > > > > > 2. Format the code base to follow The NuttX coding style
> > > > > >
> > > > > > No any change related to the kernel/user space separation, so
> it's
> > > > better
> > > > > > to contain in nuttx-apps.git in the current stage.
> > > > > > I would suggest you put the initial code inside nuttx-apps and
> move
> > > the
> > > > > > part which belongs to the kernel step by step,
> > > > > > so the community can review the change more carefully.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
I think there's a misunderstanding. Let me clarify the architecture once
more, as this has been stated several times already in this thread:
1. L2CAP and below will live in the kernel. This is the same layering as
the existing network stack — TCP/IP sits in the kernel, and that's not
controversial. L2CAP is the BLE equivalent of the transport layer. It
belongs there for the same reasons.
2. Higher-level profiles (GATT, GAP, etc.) will be moved to libc once
the full stack integration is complete. They will use standard POSIX APIs
and live in userspace, exactly as NuttX's architecture expects.
3. What you're seeing right now is Phase 1 only. This has been mentioned
in the subject and in previous messages. It's an incremental merge — we're
not dropping the entire BLE stack into the kernel and calling it done. The
final architecture will respect NuttX's layering conventions: transport in
the kernel, application-layer protocols in userspace/libc.
This is fundamentally the same pattern NuttX already follows for IP
networking. I'm not proposing anything that violates the project's
architectural values.
raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:56写道：
> Your response has nothing to do with my reply to your comment about Nimble.
> No one is claiming that the porting layer in Nimble is perfect, but it
> certainly
> doesn't use the kernel's private API.
>
> Good architecture and POSIX compliance are the core values of this project.
> It has always been this way, and I hope it remains so. For this reason,
> adding
> anything to the kernel that sits above the L4–L5 layers of the OSI model is
> a bad idea and I hope it never happens.
>
>
> pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
>
> > Hi raiden00pl,
> >
> > Regarding your point about the NimBLE port using the POSIX API — yes, it
> > uses POSIX, but there are real issues with the current implementation
> that
> > go beyond just kernel/protected mode support.
> > 1. ble_npl_hw_enter_critical is not a real critical section
> >
> > Look at the NuttX port's implementation:
> >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> >
> > static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> >
> > uint32_t ble_npl_hw_enter_critical(void)
> > {
> > pthread_mutex_lock(&s_mutex);
> > return 0;
> > }
> >
> > This is a mutex, not a critical section. It does not disable interrupts
> or
> > preemption — an ISR can still fire and corrupt data that the "critical
> > section" was supposed to protect. On top of that, using a mutex opens the
> > door to ABBA deadlocks when combined with any other lock held inside the
> > critical region:
> >
> > - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> blocked
> > by B
> > - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> >
> > Compare this with the FreeRTOS port, which correctly uses
> > vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > scheduling/preemption). The current NuttX port simply does not meet the
> > semantic contract that the NimBLE stack expects from
> > ble_npl_hw_enter_critical.
> > 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> >
> >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> >
> > ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> which
> > involves a syscall and floating-point arithmetic on every call. In a BLE
> > stack where timestamps and timing are on the hot path, this adds
> measurable
> > overhead compared to accessing the kernel tick counter directly.
> > 3. Others are already using the kernel approach — and for good reason
> >
> > A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> > uses kernel APIs directly, bypassing POSIX for the performance-critical
> > paths:
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> >
> > This isn't an academic exercise — it's a production choice. They
> recognized
> > that a BLE stack needs tight integration with the OS timer subsystem,
> > direct access to critical section primitives, and efficient event
> delivery,
> > none of which POSIX provides well in this context.
> > My question
> >
> > If other organizations are already using a more performant,
> architecturally
> > correct kernel-level integration for their BLE stacks on NuttX, why
> should
> > we be told that we must use the slower, less correct POSIX path? NuttX's
> > POSIX compliance is valuable, but it shouldn't come at the cost of
> shipping
> > a BLE stack with a broken critical section primitive. There should be
> room
> > for both approaches, and the decision should be driven by technical
> merit,
> > not by treating POSIX as the only acceptable answer.
> >
> > Best regards,
> >
> > raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
> >
> > > > We already have a similar problem with the current NimBLE
> integration.
> > > The
> > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > kernel/internal
> > > > APIs. As a result, it is difficult to support protected/kernel builds
> > > > cleanly, and it is also hard to keep the port synchronized with
> > upstream
> > > > NimBLE over time.
> > >
> > > Is this an AI analysis or something? Because it’s definitely not true:
> > > Nimble
> > > port uses the POSIX API. The only issue with kernel mode is that
> > > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> > > limitation,
> > > not a port architecture issue.
> > > I agree that synchronizing with an external repository is a challenge.
> > > However,
> > > a plus side is that we aren't the ones maintaining the code that must
> > > comply
> > > with the BLE standard.
> > >
> > > I also consider placing the entire BLE stack within the kernel to be a
> > bad
> > > idea.
> > > Even if performance isn't ideal, it’s the price one pays for a sound
> > > architecture.
> > > NuttX has always focused on addressing architectural challenges (POSIX
> > > compliance)
> > > rather than striving to be the best in terms of performance.
> > >
> > >
> > > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
> > >
> > > > No, I do not agree that the current port is only a Zephyr API
> > replacement
> > > > and
> > > > NuttX coding-style reformatting.
> > > >
> > > >
> > > >
> > > > This code base has already fixed part of the issues that still exist
> in
> > > the
> > > >
> > > > Zephyr community implementation. In addition, we still have pending
> > > > features and
> > > > fixes that have not been submitted yet. Since some of those changes
> > were
> > > > made by
> > > > other developers, I cannot submit their work by myself without proper
> > > > permission
> > > > and attribution.
> > > >
> > > >
> > > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> > > >
> > > >
> > > > I have already stated in the email why I do not recommend putting the
> > > > initial
> > > > Bluetooth host stack into nuttx-apps. Architecturally, placing it in
> > apps
> > > > would
> > > > cause significant performance degradation compared with the Zephyr
> > > design.
> > > > The
> > > > Bluetooth host stack is tightly coupled with kernel primitives,
> buffer
> > > >
> > > > management, work queues, timing, and HCI/driver paths. Moving it
> > entirely
> > > > to
> > > > apps would change that integration model and make the architecture
> > worse
> > > > from
> > > > the beginning.
> > > >
> > > >
> > > >
> > > > Therefore, please read my previous email more carefully. The concern
> > here
> > > > is not
> > > > only the initial review size, but also the long-term architecture and
> > > > runtime
> > > > performance of the Bluetooth stack in NuttX.
> > > >
> > > > BRs,
> > > >
> > > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> > > >
> > > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I would like to summarize the background, technical motivation,
> and
> > > > > > proposed evolution plan for PR #20686, which introduces a
> > > Zephyr-based
> > > > > > Bluetooth host stack under net/bt.
> > > > > >
> > > > > > https://github.com/apache/nuttx/pull/20686
> > > > > >
> > > > > > First of all, I fully understand the concerns raised in the
> > > discussion.
> > > > > > Adding a new Bluetooth stack is a significant architectural
> change,
> > > and
> > > > > it
> > > > > > is reasonable for the community to ask whether we should instead
> > > > continue
> > > > > > improving the existing NuttX Bluetooth implementation. I would
> like
> > > to
> > > > > > explain why we believe introducing the new stack incrementally is
> > the
> > > > > more
> > > > > > practical path, while still keeping the long-term NuttX
> > architecture
> > > > > clean
> > > > > > and maintainable.
> > > > > > ------------------------------
> > > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > > > > >
> > > > > > The existing NuttX Bluetooth implementation is mainly focused on
> > BLE
> > > > > > functionality. However, modern Bluetooth support is no longer
> > limited
> > > > to
> > > > > > basic BLE. A complete Bluetooth host stack now commonly includes:
> > > > > >
> > > > > > - BLE GAP/GATT/ATT/SMP
> > > > > > - Classic Bluetooth profiles
> > > > > > - A2DP
> > > > > > - AVRCP
> > > > > > - HFP/HSP
> > > > > > - HID
> > > > > > - LE Mesh
> > > > > > - LE Audio
> > > > > > - Additional profile-level interoperability logic
> > > > > >
> > > > > >
> > > > > But most of these profiles should belong to the userspace, please
> > split
> > > > the
> > > > > related code to nuttx-apps.git, instead nuttx/.
> > > > > especially, the code related shell spread in the whole code base:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > > > > it's definitely wrong to put the shell code inside kernel space.
> > > > >
> > > > >
> > > > > > The Zephyr Bluetooth stack already provides a broad and actively
> > > > > maintained
> > > > > > implementation across many of these areas. Rebuilding equivalent
> > > > > > functionality directly on top of the current NuttX Bluetooth
> stack
> > > > would
> > > > > > require a very large multi-year effort, including not only
> protocol
> > > > > > implementation but also interoperability testing with real
> phones,
> > > > > > headsets, speakers, cars, and other commercial devices.
> > > > > >
> > > > > > Therefore, our goal is not to discard NuttX's existing work
> > lightly,
> > > > but
> > > > > to
> > > > > > provide a practical path to make NuttX capable of supporting a
> much
> > > > wider
> > > > > > Bluetooth feature set in a reasonable time frame.
> > > > > > ------------------------------
> > > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > > > > >
> > > > > > Another important discussion point is whether the new Bluetooth
> > stack
> > > > > > should live in nuttx-apps, similar to how NimBLE is currently
> > > > integrated.
> > > > > >
> > > > > > Our concern is that a host stack is not just an application-level
> > > > > > component. It interacts closely with:
> > > > > >
> > > > > > - HCI transport
> > > > > > - L2CAP channels
> > > > > > - Socket or device interfaces
> > > > > > - Memory pools
> > > > > > - Timers and work queues
> > > > > > - Security and pairing state
> > > > > > - Profile registration
> > > > > > - Controller event dispatch
> > > > > > - Future kernel/user boundary mechanisms
> > > > > >
> > > > > > Putting the core host stack in nuttx-apps would either require
> > > exposing
> > > > > > many internal kernel interfaces or would force the
> application-side
> > > > stack
> > > > > > to depend on non-public NuttX internals.
> > > > > >
> > > > > > We already have a similar problem with the current NimBLE
> > > integration.
> > > > > The
> > > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > > > kernel/internal
> > > > > > APIs. As a result, it is difficult to support protected/kernel
> > builds
> > > > > > cleanly, and it is also hard to keep the port synchronized with
> > > > upstream
> > > > > > NimBLE over time.
> > > > > >
> > > > > >
> > > > > These are kernel public API, the only problem is that they are
> called
> > > by
> > > > > userspace.
> > > > >
> > > > >
> > > > > > For this reason, we believe the Bluetooth host core belongs in
> the
> > > > NuttX
> > > > > > tree. User-facing profiles, tools, shell commands, or demo
> > > applications
> > > > > can
> > > > > > still live outside the core as appropriate, but the
> > transport-facing
> > > > host
> > > > > > stack should have a well-defined place inside NuttX.
> > > > > >
> > > > > > There is also a performance consideration. In flat build mode,
> the
> > > > > > Bluetooth host stack can run directly on the kernel side without
> > > > > additional
> > > > > > syscall or user/kernel boundary overhead. This is especially
> > > important
> > > > > for
> > > > > > IoT chips with relatively low CPU frequency, where Bluetooth data
> > > path
> > > > > and
> > > > > > profile handling overhead can have a visible impact on
> throughput,
> > > > > latency,
> > > > > > and power consumption.
> > > > > >
> > > > > > At the same time, this does not mean that the final architecture
> > must
> > > > > > remain flat-build-only. A compatible evolution path is to keep
> the
> > > > > > performance-sensitive transport and host core on the kernel side,
> > > while
> > > > > > gradually moving suitable Bluetooth profile implementations or
> > > > > > profile-facing helper layers into libc-visible build paths. This
> > > allows
> > > > > > protected and kernel builds to use proper public interfaces,
> while
> > > > still
> > > > > > preserving good performance for flat build and low-end IoT
> > platforms.
> > > > > >
> > > > > > In other words, placing the stack in nuttx gives us a cleaner
> > > long-term
> > > > > > architecture:
> > > > > >
> > > > > > - Flat build can get the best performance with minimum
> overhead.
> > > > > > - Protected/kernel build can be supported later through proper
> > > > public
> > > > > > interfaces.
> > > > > > - Profile code can be migrated into libc-compatible paths
> where
> > > > > > appropriate.
> > > > > > - Userspace does not need to directly depend on private kernel
> > > > > symbols.
> > > > > > - The design avoids repeating the long-term maintainability
> > issue
> > > > seen
> > > > > > in some existing userspace Bluetooth integrations.
> > > > > >
> > > > > >
> > > > >
> > > > > But Zephyr bluetooth stack is implemented as a monolithic block
> like
> > > > > NimBLE.
> > > > > Your current porting just include:
> > > > >
> > > > > 1. Switch Zephyr API to NuttX kernel API
> > > > > 2. Format the code base to follow The NuttX coding style
> > > > >
> > > > > No any change related to the kernel/user space separation, so it's
> > > better
> > > > > to contain in nuttx-apps.git in the current stage.
> > > > > I would suggest you put the initial code inside nuttx-apps and move
> > the
> > > > > part which belongs to the kernel step by step,
> > > > > so the community can review the change more carefully.
> > > > >
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi, raiden,
1. I have used NimBLE — it was actually one of the candidates during our
initial stack evaluation. In fact, we evaluated a wide range of open-source
Bluetooth stacks: BTstack, NimBLE, Zephyr, Android Fluoride, and others.
You can still find my personal repositories with early ports of zblue and
Fluoride for Xiaomi. I've personally tried almost every open-source
Bluetooth stack out there — which is why I have a fairly deep understanding
of this space. Ultimately we chose to port directly from the Zephyr stack
because it has the broadest feature set and most active upstream
development. NimBLE, for what it's worth, is also derived from the same
Zephyr/Mynewt lineage.
2. The 200 MB/s number in the mail was a typo — it should be 200 KB/s
(3M PHY). Apologies for the confusion, that's a fair catch.
If we can get this merged, I'd especially welcome your involvement in
building out the stack together. It covers nearly the full range of
Bluetooth capabilities (BR/EDR, BLE, LE Audio, LE Mesh, etc.), so there's
more than enough work to go around.
raiden00pl <ra...@gmail.com> 于2026年10月16日周五 20:19写道：
> > First, we are not using NimBLE — we are using the zblue stack from
> > openvela/Xiaomi, which has a different architecture and different
> > performance characteristics than NimBLE. Please don't conflate the two.
>
> but you’re the one bringing up false information about Nimble, without even
> having used it :)
>
> I'm not criticizing the idea of porting the Zephyr stack to NuttX, I'm
> criticizing the false
> information used to defend that idea, as well as the inclusion of
> components in the kernel
> that don't belong there (even if added only temporarily to master).
> The very idea of a better BL/BLE stack (in this case, ported from Zephyr)
> is good,
> even if I personally prefer using NimBLE.
>
> > Regarding your skepticism about the SPP bandwidth example: have you ever
> > worked with BLE chips used in LED lighting products? This is a massive
> > category in smart home. Let me give you a concrete example.
>
> Mentioned in your PR SPP bandwidth at 200 MB/s is not skepticism, it's just
> physically impossible.
>
> > I'm curious: what would your solution be for a chip like this — 80 MHz
> M0,
> > 64 KB flash, 64 KB RAM, needing to run both NuttX and a Bluetooth stack?
>
> If something is impossible for NuttX, then perhaps NuttX isn't the right
> tool for the job?
> No one claims that NuttX is perfect for everything.
>
> pt., 16 paź 2026 o 14:00 chao an <ma...@gmail.com> napisał(a):
>
> > Hi, raiden
> >
> > First, we are not using NimBLE — we are using the zblue stack from
> > openvela/Xiaomi, which has a different architecture and different
> > performance characteristics than NimBLE. Please don't conflate the two.
> >
> > Regarding your skepticism about the SPP bandwidth example: have you ever
> > worked with BLE chips used in LED lighting products? This is a massive
> > category in smart home. Let me give you a concrete example.
> >
> > We previously worked with a Chinese chip vendor called Onmicro. Their BLE
> > SoC uses a Cortex-M0 core at 80 MHz, with only 64 KB flash and 64 KB RAM.
> > On this platform, just fitting NuttX itself is a challenge, let alone
> > running a full-featured Bluetooth stack. To support this chip and
> maximize
> > HCI throughput, we introduced the btdrv layer in the NuttX stack — a recv
> > hook that delivers HCI data directly from the controller to the host
> stack,
> > bypassing the VFS entirely.
> >
> > Let me break down the alternative path that we specifically avoided for
> > this chip:
> >
> > Controller IRQ → btdrv → VFS → host stack
> >
> > This path requires two thread context switches and two memory copies on
> > every HCI packet. On an 80 MHz Cortex-M0, that's not negligible — it's
> the
> > difference between the stack being usable or not.
> >
> > For more capable chips, we still use the standard VFS-based approach —
> the
> > btdrv direct path is only enabled on resource-constrained platforms. So
> > this optimization doesn't affect richer platforms at all.
> >
> > I'm curious: what would your solution be for a chip like this — 80 MHz
> M0,
> > 64 KB flash, 64 KB RAM, needing to run both NuttX and a Bluetooth stack?
> >
> > By the way, you're a Xiaomi contractor — you can ask Xiaoxiang on Lark
> > directly whether what I'm saying is accurate. He's familiar with the full
> > details of this project.
> >
> > raiden00pl <ra...@gmail.com> 于2026年10月16日周五 15:07写道：
> >
> > > Also, if you’re talking about performance, it would be appropriate to
> > back
> > > that up with some real data.
> > >
> > > From your PR:
> > >
> > > > with CPU frequencies below 100 MHz — this copying becomes very
> costly.
> > > For example, with SPP bandwidth at 200 MB/s, this alone can consume
> more
> > > than 15% CPU load.
> > >
> > > This is total nonsense. SPP can't achieve 200 MB/s, it is impossible !
> > >
> > > Sorry, but your claims regarding Nimble were simply false, furthermore,
> > the
> > > example you provided abot SSP is also nonsense. I don’t like that.
> > >
> > > pt., 16 paź 2026 o 08:55 raiden00pl <ra...@gmail.com> napisał(a):
> > >
> > > > Your response has nothing to do with my reply to your comment about
> > > > Nimble.
> > > > No one is claiming that the porting layer in Nimble is perfect, but
> it
> > > > certainly
> > > > doesn't use the kernel's private API.
> > > >
> > > > Good architecture and POSIX compliance are the core values of this
> > > > project.
> > > > It has always been this way, and I hope it remains so. For this
> reason,
> > > > adding
> > > > anything to the kernel that sits above the L4–L5 layers of the OSI
> > model
> > > > is
> > > > a bad idea and I hope it never happens.
> > > >
> > > >
> > > > pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
> > > >
> > > >> Hi raiden00pl,
> > > >>
> > > >> Regarding your point about the NimBLE port using the POSIX API —
> yes,
> > it
> > > >> uses POSIX, but there are real issues with the current
> implementation
> > > that
> > > >> go beyond just kernel/protected mode support.
> > > >> 1. ble_npl_hw_enter_critical is not a real critical section
> > > >>
> > > >> Look at the NuttX port's implementation:
> > > >>
> > > >>
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > > >>
> > > >> static pthread_mutex_t s_mutex =
> > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > >>
> > > >> uint32_t ble_npl_hw_enter_critical(void)
> > > >> {
> > > >> pthread_mutex_lock(&s_mutex);
> > > >> return 0;
> > > >> }
> > > >>
> > > >> This is a mutex, not a critical section. It does not disable
> > interrupts
> > > or
> > > >> preemption — an ISR can still fire and corrupt data that the
> "critical
> > > >> section" was supposed to protect. On top of that, using a mutex
> opens
> > > the
> > > >> door to ABBA deadlocks when combined with any other lock held inside
> > the
> > > >> critical region:
> > > >>
> > > >> - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > > >> blocked
> > > >> by B
> > > >> - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked
> by A
> > > >>
> > > >> Compare this with the FreeRTOS port, which correctly uses
> > > >> vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > > >> scheduling/preemption). The current NuttX port simply does not meet
> > the
> > > >> semantic contract that the NimBLE stack expects from
> > > >> ble_npl_hw_enter_critical.
> > > >> 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > > >>
> > > >>
> > > >>
> > >
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > > >>
> > > >> ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > > which
> > > >> involves a syscall and floating-point arithmetic on every call. In a
> > BLE
> > > >> stack where timestamps and timing are on the hot path, this adds
> > > >> measurable
> > > >> overhead compared to accessing the kernel tick counter directly.
> > > >> 3. Others are already using the kernel approach — and for good
> reason
> > > >>
> > > >> A concrete example: Xiaomi's Bluetooth stack (zblue) for
> > openvela/NuttX
> > > >> uses kernel APIs directly, bypassing POSIX for the
> > performance-critical
> > > >> paths:
> > > >>
> > >
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > >>
> > > >> This isn't an academic exercise — it's a production choice. They
> > > >> recognized
> > > >> that a BLE stack needs tight integration with the OS timer
> subsystem,
> > > >> direct access to critical section primitives, and efficient event
> > > >> delivery,
> > > >> none of which POSIX provides well in this context.
> > > >> My question
> > > >>
> > > >> If other organizations are already using a more performant,
> > > >> architecturally
> > > >> correct kernel-level integration for their BLE stacks on NuttX, why
> > > should
> > > >> we be told that we must use the slower, less correct POSIX path?
> > NuttX's
> > > >> POSIX compliance is valuable, but it shouldn't come at the cost of
> > > >> shipping
> > > >> a BLE stack with a broken critical section primitive. There should
> be
> > > room
> > > >> for both approaches, and the decision should be driven by technical
> > > merit,
> > > >> not by treating POSIX as the only acceptable answer.
> > > >>
> > > >> Best regards,
> > > >>
> > > >> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
> > > >>
> > > >> > > We already have a similar problem with the current NimBLE
> > > integration.
> > > >> > The
> > > >> > > NimBLE port in nuttx-apps directly depends on many NuttX
> > > >> kernel/internal
> > > >> > > APIs. As a result, it is difficult to support protected/kernel
> > > builds
> > > >> > > cleanly, and it is also hard to keep the port synchronized with
> > > >> upstream
> > > >> > > NimBLE over time.
> > > >> >
> > > >> > Is this an AI analysis or something? Because it’s definitely not
> > true:
> > > >> > Nimble
> > > >> > port uses the POSIX API. The only issue with kernel mode is that
> > > >> > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> > > >> > limitation,
> > > >> > not a port architecture issue.
> > > >> > I agree that synchronizing with an external repository is a
> > challenge.
> > > >> > However,
> > > >> > a plus side is that we aren't the ones maintaining the code that
> > must
> > > >> > comply
> > > >> > with the BLE standard.
> > > >> >
> > > >> > I also consider placing the entire BLE stack within the kernel to
> > be a
> > > >> bad
> > > >> > idea.
> > > >> > Even if performance isn't ideal, it’s the price one pays for a
> sound
> > > >> > architecture.
> > > >> > NuttX has always focused on addressing architectural challenges
> > (POSIX
> > > >> > compliance)
> > > >> > rather than striving to be the best in terms of performance.
> > > >> >
> > > >> >
> > > >> > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com>
> napisał(a):
> > > >> >
> > > >> > > No, I do not agree that the current port is only a Zephyr API
> > > >> replacement
> > > >> > > and
> > > >> > > NuttX coding-style reformatting.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > This code base has already fixed part of the issues that still
> > exist
> > > >> in
> > > >> > the
> > > >> > >
> > > >> > > Zephyr community implementation. In addition, we still have
> > pending
> > > >> > > features and
> > > >> > > fixes that have not been submitted yet. Since some of those
> > changes
> > > >> were
> > > >> > > made by
> > > >> > > other developers, I cannot submit their work by myself without
> > > proper
> > > >> > > permission
> > > >> > > and attribution.
> > > >> > >
> > > >> > >
> > > >> > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> > > >> > >
> > > >> > >
> > > >> > > I have already stated in the email why I do not recommend
> putting
> > > the
> > > >> > > initial
> > > >> > > Bluetooth host stack into nuttx-apps. Architecturally, placing
> it
> > in
> > > >> apps
> > > >> > > would
> > > >> > > cause significant performance degradation compared with the
> Zephyr
> > > >> > design.
> > > >> > > The
> > > >> > > Bluetooth host stack is tightly coupled with kernel primitives,
> > > buffer
> > > >> > >
> > > >> > > management, work queues, timing, and HCI/driver paths. Moving it
> > > >> entirely
> > > >> > > to
> > > >> > > apps would change that integration model and make the
> architecture
> > > >> worse
> > > >> > > from
> > > >> > > the beginning.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Therefore, please read my previous email more carefully. The
> > concern
> > > >> here
> > > >> > > is not
> > > >> > > only the initial review size, but also the long-term
> architecture
> > > and
> > > >> > > runtime
> > > >> > > performance of the Bluetooth stack in NuttX.
> > > >> > >
> > > >> > > BRs,
> > > >> > >
> > > >> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> > > >> > >
> > > >> > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <magicdcps@gmail.com
> >
> > > >> wrote:
> > > >> > > >
> > > >> > > > > Hi all,
> > > >> > > > >
> > > >> > > > > I would like to summarize the background, technical
> > motivation,
> > > >> and
> > > >> > > > > proposed evolution plan for PR #20686, which introduces a
> > > >> > Zephyr-based
> > > >> > > > > Bluetooth host stack under net/bt.
> > > >> > > > >
> > > >> > > > > https://github.com/apache/nuttx/pull/20686
> > > >> > > > >
> > > >> > > > > First of all, I fully understand the concerns raised in the
> > > >> > discussion.
> > > >> > > > > Adding a new Bluetooth stack is a significant architectural
> > > >> change,
> > > >> > and
> > > >> > > > it
> > > >> > > > > is reasonable for the community to ask whether we should
> > instead
> > > >> > > continue
> > > >> > > > > improving the existing NuttX Bluetooth implementation. I
> would
> > > >> like
> > > >> > to
> > > >> > > > > explain why we believe introducing the new stack
> incrementally
> > > is
> > > >> the
> > > >> > > > more
> > > >> > > > > practical path, while still keeping the long-term NuttX
> > > >> architecture
> > > >> > > > clean
> > > >> > > > > and maintainable.
> > > >> > > > > ------------------------------
> > > >> > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > > >> > > > >
> > > >> > > > > The existing NuttX Bluetooth implementation is mainly
> focused
> > on
> > > >> BLE
> > > >> > > > > functionality. However, modern Bluetooth support is no
> longer
> > > >> limited
> > > >> > > to
> > > >> > > > > basic BLE. A complete Bluetooth host stack now commonly
> > > includes:
> > > >> > > > >
> > > >> > > > > - BLE GAP/GATT/ATT/SMP
> > > >> > > > > - Classic Bluetooth profiles
> > > >> > > > > - A2DP
> > > >> > > > > - AVRCP
> > > >> > > > > - HFP/HSP
> > > >> > > > > - HID
> > > >> > > > > - LE Mesh
> > > >> > > > > - LE Audio
> > > >> > > > > - Additional profile-level interoperability logic
> > > >> > > > >
> > > >> > > > >
> > > >> > > > But most of these profiles should belong to the userspace,
> > please
> > > >> split
> > > >> > > the
> > > >> > > > related code to nuttx-apps.git, instead nuttx/.
> > > >> > > > especially, the code related shell spread in the whole code
> > base:
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > > >> > > > it's definitely wrong to put the shell code inside kernel
> space.
> > > >> > > >
> > > >> > > >
> > > >> > > > > The Zephyr Bluetooth stack already provides a broad and
> > actively
> > > >> > > > maintained
> > > >> > > > > implementation across many of these areas. Rebuilding
> > equivalent
> > > >> > > > > functionality directly on top of the current NuttX Bluetooth
> > > stack
> > > >> > > would
> > > >> > > > > require a very large multi-year effort, including not only
> > > >> protocol
> > > >> > > > > implementation but also interoperability testing with real
> > > phones,
> > > >> > > > > headsets, speakers, cars, and other commercial devices.
> > > >> > > > >
> > > >> > > > > Therefore, our goal is not to discard NuttX's existing work
> > > >> lightly,
> > > >> > > but
> > > >> > > > to
> > > >> > > > > provide a practical path to make NuttX capable of
> supporting a
> > > >> much
> > > >> > > wider
> > > >> > > > > Bluetooth feature set in a reasonable time frame.
> > > >> > > > > ------------------------------
> > > >> > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > > >> > > > >
> > > >> > > > > Another important discussion point is whether the new
> > Bluetooth
> > > >> stack
> > > >> > > > > should live in nuttx-apps, similar to how NimBLE is
> currently
> > > >> > > integrated.
> > > >> > > > >
> > > >> > > > > Our concern is that a host stack is not just an
> > > application-level
> > > >> > > > > component. It interacts closely with:
> > > >> > > > >
> > > >> > > > > - HCI transport
> > > >> > > > > - L2CAP channels
> > > >> > > > > - Socket or device interfaces
> > > >> > > > > - Memory pools
> > > >> > > > > - Timers and work queues
> > > >> > > > > - Security and pairing state
> > > >> > > > > - Profile registration
> > > >> > > > > - Controller event dispatch
> > > >> > > > > - Future kernel/user boundary mechanisms
> > > >> > > > >
> > > >> > > > > Putting the core host stack in nuttx-apps would either
> require
> > > >> > exposing
> > > >> > > > > many internal kernel interfaces or would force the
> > > >> application-side
> > > >> > > stack
> > > >> > > > > to depend on non-public NuttX internals.
> > > >> > > > >
> > > >> > > > > We already have a similar problem with the current NimBLE
> > > >> > integration.
> > > >> > > > The
> > > >> > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > > >> > > kernel/internal
> > > >> > > > > APIs. As a result, it is difficult to support
> protected/kernel
> > > >> builds
> > > >> > > > > cleanly, and it is also hard to keep the port synchronized
> > with
> > > >> > > upstream
> > > >> > > > > NimBLE over time.
> > > >> > > > >
> > > >> > > > >
> > > >> > > > These are kernel public API, the only problem is that they are
> > > >> called
> > > >> > by
> > > >> > > > userspace.
> > > >> > > >
> > > >> > > >
> > > >> > > > > For this reason, we believe the Bluetooth host core belongs
> in
> > > the
> > > >> > > NuttX
> > > >> > > > > tree. User-facing profiles, tools, shell commands, or demo
> > > >> > applications
> > > >> > > > can
> > > >> > > > > still live outside the core as appropriate, but the
> > > >> transport-facing
> > > >> > > host
> > > >> > > > > stack should have a well-defined place inside NuttX.
> > > >> > > > >
> > > >> > > > > There is also a performance consideration. In flat build
> mode,
> > > the
> > > >> > > > > Bluetooth host stack can run directly on the kernel side
> > without
> > > >> > > > additional
> > > >> > > > > syscall or user/kernel boundary overhead. This is especially
> > > >> > important
> > > >> > > > for
> > > >> > > > > IoT chips with relatively low CPU frequency, where Bluetooth
> > > data
> > > >> > path
> > > >> > > > and
> > > >> > > > > profile handling overhead can have a visible impact on
> > > throughput,
> > > >> > > > latency,
> > > >> > > > > and power consumption.
> > > >> > > > >
> > > >> > > > > At the same time, this does not mean that the final
> > architecture
> > > >> must
> > > >> > > > > remain flat-build-only. A compatible evolution path is to
> keep
> > > the
> > > >> > > > > performance-sensitive transport and host core on the kernel
> > > side,
> > > >> > while
> > > >> > > > > gradually moving suitable Bluetooth profile implementations
> or
> > > >> > > > > profile-facing helper layers into libc-visible build paths.
> > This
> > > >> > allows
> > > >> > > > > protected and kernel builds to use proper public interfaces,
> > > while
> > > >> > > still
> > > >> > > > > preserving good performance for flat build and low-end IoT
> > > >> platforms.
> > > >> > > > >
> > > >> > > > > In other words, placing the stack in nuttx gives us a
> cleaner
> > > >> > long-term
> > > >> > > > > architecture:
> > > >> > > > >
> > > >> > > > > - Flat build can get the best performance with minimum
> > > >> overhead.
> > > >> > > > > - Protected/kernel build can be supported later through
> > > proper
> > > >> > > public
> > > >> > > > > interfaces.
> > > >> > > > > - Profile code can be migrated into libc-compatible paths
> > > where
> > > >> > > > > appropriate.
> > > >> > > > > - Userspace does not need to directly depend on private
> > > kernel
> > > >> > > > symbols.
> > > >> > > > > - The design avoids repeating the long-term
> maintainability
> > > >> issue
> > > >> > > seen
> > > >> > > > > in some existing userspace Bluetooth integrations.
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > > But Zephyr bluetooth stack is implemented as a monolithic
> block
> > > like
> > > >> > > > NimBLE.
> > > >> > > > Your current porting just include:
> > > >> > > >
> > > >> > > > 1. Switch Zephyr API to NuttX kernel API
> > > >> > > > 2. Format the code base to follow The NuttX coding style
> > > >> > > >
> > > >> > > > No any change related to the kernel/user space separation, so
> > it's
> > > >> > better
> > > >> > > > to contain in nuttx-apps.git in the current stage.
> > > >> > > > I would suggest you put the initial code inside nuttx-apps and
> > > move
> > > >> the
> > > >> > > > part which belongs to the kernel step by step,
> > > >> > > > so the community can review the change more carefully.
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by raiden00pl <ra...@gmail.com>.
> First, we are not using NimBLE — we are using the zblue stack from
> openvela/Xiaomi, which has a different architecture and different
> performance characteristics than NimBLE. Please don't conflate the two.
but you’re the one bringing up false information about Nimble, without even
having used it :)
I'm not criticizing the idea of porting the Zephyr stack to NuttX, I'm
criticizing the false
information used to defend that idea, as well as the inclusion of
components in the kernel
that don't belong there (even if added only temporarily to master).
The very idea of a better BL/BLE stack (in this case, ported from Zephyr)
is good,
even if I personally prefer using NimBLE.
> Regarding your skepticism about the SPP bandwidth example: have you ever
> worked with BLE chips used in LED lighting products? This is a massive
> category in smart home. Let me give you a concrete example.
Mentioned in your PR SPP bandwidth at 200 MB/s is not skepticism, it's just
physically impossible.
> I'm curious: what would your solution be for a chip like this — 80 MHz M0,
> 64 KB flash, 64 KB RAM, needing to run both NuttX and a Bluetooth stack?
If something is impossible for NuttX, then perhaps NuttX isn't the right
tool for the job?
No one claims that NuttX is perfect for everything.
pt., 16 paź 2026 o 14:00 chao an <ma...@gmail.com> napisał(a):
> Hi, raiden
>
> First, we are not using NimBLE — we are using the zblue stack from
> openvela/Xiaomi, which has a different architecture and different
> performance characteristics than NimBLE. Please don't conflate the two.
>
> Regarding your skepticism about the SPP bandwidth example: have you ever
> worked with BLE chips used in LED lighting products? This is a massive
> category in smart home. Let me give you a concrete example.
>
> We previously worked with a Chinese chip vendor called Onmicro. Their BLE
> SoC uses a Cortex-M0 core at 80 MHz, with only 64 KB flash and 64 KB RAM.
> On this platform, just fitting NuttX itself is a challenge, let alone
> running a full-featured Bluetooth stack. To support this chip and maximize
> HCI throughput, we introduced the btdrv layer in the NuttX stack — a recv
> hook that delivers HCI data directly from the controller to the host stack,
> bypassing the VFS entirely.
>
> Let me break down the alternative path that we specifically avoided for
> this chip:
>
> Controller IRQ → btdrv → VFS → host stack
>
> This path requires two thread context switches and two memory copies on
> every HCI packet. On an 80 MHz Cortex-M0, that's not negligible — it's the
> difference between the stack being usable or not.
>
> For more capable chips, we still use the standard VFS-based approach — the
> btdrv direct path is only enabled on resource-constrained platforms. So
> this optimization doesn't affect richer platforms at all.
>
> I'm curious: what would your solution be for a chip like this — 80 MHz M0,
> 64 KB flash, 64 KB RAM, needing to run both NuttX and a Bluetooth stack?
>
> By the way, you're a Xiaomi contractor — you can ask Xiaoxiang on Lark
> directly whether what I'm saying is accurate. He's familiar with the full
> details of this project.
>
> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 15:07写道：
>
> > Also, if you’re talking about performance, it would be appropriate to
> back
> > that up with some real data.
> >
> > From your PR:
> >
> > > with CPU frequencies below 100 MHz — this copying becomes very costly.
> > For example, with SPP bandwidth at 200 MB/s, this alone can consume more
> > than 15% CPU load.
> >
> > This is total nonsense. SPP can't achieve 200 MB/s, it is impossible !
> >
> > Sorry, but your claims regarding Nimble were simply false, furthermore,
> the
> > example you provided abot SSP is also nonsense. I don’t like that.
> >
> > pt., 16 paź 2026 o 08:55 raiden00pl <ra...@gmail.com> napisał(a):
> >
> > > Your response has nothing to do with my reply to your comment about
> > > Nimble.
> > > No one is claiming that the porting layer in Nimble is perfect, but it
> > > certainly
> > > doesn't use the kernel's private API.
> > >
> > > Good architecture and POSIX compliance are the core values of this
> > > project.
> > > It has always been this way, and I hope it remains so. For this reason,
> > > adding
> > > anything to the kernel that sits above the L4–L5 layers of the OSI
> model
> > > is
> > > a bad idea and I hope it never happens.
> > >
> > >
> > > pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
> > >
> > >> Hi raiden00pl,
> > >>
> > >> Regarding your point about the NimBLE port using the POSIX API — yes,
> it
> > >> uses POSIX, but there are real issues with the current implementation
> > that
> > >> go beyond just kernel/protected mode support.
> > >> 1. ble_npl_hw_enter_critical is not a real critical section
> > >>
> > >> Look at the NuttX port's implementation:
> > >>
> > >>
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> > >>
> > >> static pthread_mutex_t s_mutex =
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > >>
> > >> uint32_t ble_npl_hw_enter_critical(void)
> > >> {
> > >> pthread_mutex_lock(&s_mutex);
> > >> return 0;
> > >> }
> > >>
> > >> This is a mutex, not a critical section. It does not disable
> interrupts
> > or
> > >> preemption — an ISR can still fire and corrupt data that the "critical
> > >> section" was supposed to protect. On top of that, using a mutex opens
> > the
> > >> door to ABBA deadlocks when combined with any other lock held inside
> the
> > >> critical region:
> > >>
> > >> - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> > >> blocked
> > >> by B
> > >> - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> > >>
> > >> Compare this with the FreeRTOS port, which correctly uses
> > >> vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> > >> scheduling/preemption). The current NuttX port simply does not meet
> the
> > >> semantic contract that the NimBLE stack expects from
> > >> ble_npl_hw_enter_critical.
> > >> 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> > >>
> > >>
> > >>
> >
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> > >>
> > >> ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> > which
> > >> involves a syscall and floating-point arithmetic on every call. In a
> BLE
> > >> stack where timestamps and timing are on the hot path, this adds
> > >> measurable
> > >> overhead compared to accessing the kernel tick counter directly.
> > >> 3. Others are already using the kernel approach — and for good reason
> > >>
> > >> A concrete example: Xiaomi's Bluetooth stack (zblue) for
> openvela/NuttX
> > >> uses kernel APIs directly, bypassing POSIX for the
> performance-critical
> > >> paths:
> > >>
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > >>
> > >> This isn't an academic exercise — it's a production choice. They
> > >> recognized
> > >> that a BLE stack needs tight integration with the OS timer subsystem,
> > >> direct access to critical section primitives, and efficient event
> > >> delivery,
> > >> none of which POSIX provides well in this context.
> > >> My question
> > >>
> > >> If other organizations are already using a more performant,
> > >> architecturally
> > >> correct kernel-level integration for their BLE stacks on NuttX, why
> > should
> > >> we be told that we must use the slower, less correct POSIX path?
> NuttX's
> > >> POSIX compliance is valuable, but it shouldn't come at the cost of
> > >> shipping
> > >> a BLE stack with a broken critical section primitive. There should be
> > room
> > >> for both approaches, and the decision should be driven by technical
> > merit,
> > >> not by treating POSIX as the only acceptable answer.
> > >>
> > >> Best regards,
> > >>
> > >> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
> > >>
> > >> > > We already have a similar problem with the current NimBLE
> > integration.
> > >> > The
> > >> > > NimBLE port in nuttx-apps directly depends on many NuttX
> > >> kernel/internal
> > >> > > APIs. As a result, it is difficult to support protected/kernel
> > builds
> > >> > > cleanly, and it is also hard to keep the port synchronized with
> > >> upstream
> > >> > > NimBLE over time.
> > >> >
> > >> > Is this an AI analysis or something? Because it’s definitely not
> true:
> > >> > Nimble
> > >> > port uses the POSIX API. The only issue with kernel mode is that
> > >> > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> > >> > limitation,
> > >> > not a port architecture issue.
> > >> > I agree that synchronizing with an external repository is a
> challenge.
> > >> > However,
> > >> > a plus side is that we aren't the ones maintaining the code that
> must
> > >> > comply
> > >> > with the BLE standard.
> > >> >
> > >> > I also consider placing the entire BLE stack within the kernel to
> be a
> > >> bad
> > >> > idea.
> > >> > Even if performance isn't ideal, it’s the price one pays for a sound
> > >> > architecture.
> > >> > NuttX has always focused on addressing architectural challenges
> (POSIX
> > >> > compliance)
> > >> > rather than striving to be the best in terms of performance.
> > >> >
> > >> >
> > >> > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
> > >> >
> > >> > > No, I do not agree that the current port is only a Zephyr API
> > >> replacement
> > >> > > and
> > >> > > NuttX coding-style reformatting.
> > >> > >
> > >> > >
> > >> > >
> > >> > > This code base has already fixed part of the issues that still
> exist
> > >> in
> > >> > the
> > >> > >
> > >> > > Zephyr community implementation. In addition, we still have
> pending
> > >> > > features and
> > >> > > fixes that have not been submitted yet. Since some of those
> changes
> > >> were
> > >> > > made by
> > >> > > other developers, I cannot submit their work by myself without
> > proper
> > >> > > permission
> > >> > > and attribution.
> > >> > >
> > >> > >
> > >> > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> > >> > >
> > >> > >
> > >> > > I have already stated in the email why I do not recommend putting
> > the
> > >> > > initial
> > >> > > Bluetooth host stack into nuttx-apps. Architecturally, placing it
> in
> > >> apps
> > >> > > would
> > >> > > cause significant performance degradation compared with the Zephyr
> > >> > design.
> > >> > > The
> > >> > > Bluetooth host stack is tightly coupled with kernel primitives,
> > buffer
> > >> > >
> > >> > > management, work queues, timing, and HCI/driver paths. Moving it
> > >> entirely
> > >> > > to
> > >> > > apps would change that integration model and make the architecture
> > >> worse
> > >> > > from
> > >> > > the beginning.
> > >> > >
> > >> > >
> > >> > >
> > >> > > Therefore, please read my previous email more carefully. The
> concern
> > >> here
> > >> > > is not
> > >> > > only the initial review size, but also the long-term architecture
> > and
> > >> > > runtime
> > >> > > performance of the Bluetooth stack in NuttX.
> > >> > >
> > >> > > BRs,
> > >> > >
> > >> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> > >> > >
> > >> > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com>
> > >> wrote:
> > >> > > >
> > >> > > > > Hi all,
> > >> > > > >
> > >> > > > > I would like to summarize the background, technical
> motivation,
> > >> and
> > >> > > > > proposed evolution plan for PR #20686, which introduces a
> > >> > Zephyr-based
> > >> > > > > Bluetooth host stack under net/bt.
> > >> > > > >
> > >> > > > > https://github.com/apache/nuttx/pull/20686
> > >> > > > >
> > >> > > > > First of all, I fully understand the concerns raised in the
> > >> > discussion.
> > >> > > > > Adding a new Bluetooth stack is a significant architectural
> > >> change,
> > >> > and
> > >> > > > it
> > >> > > > > is reasonable for the community to ask whether we should
> instead
> > >> > > continue
> > >> > > > > improving the existing NuttX Bluetooth implementation. I would
> > >> like
> > >> > to
> > >> > > > > explain why we believe introducing the new stack incrementally
> > is
> > >> the
> > >> > > > more
> > >> > > > > practical path, while still keeping the long-term NuttX
> > >> architecture
> > >> > > > clean
> > >> > > > > and maintainable.
> > >> > > > > ------------------------------
> > >> > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > >> > > > >
> > >> > > > > The existing NuttX Bluetooth implementation is mainly focused
> on
> > >> BLE
> > >> > > > > functionality. However, modern Bluetooth support is no longer
> > >> limited
> > >> > > to
> > >> > > > > basic BLE. A complete Bluetooth host stack now commonly
> > includes:
> > >> > > > >
> > >> > > > > - BLE GAP/GATT/ATT/SMP
> > >> > > > > - Classic Bluetooth profiles
> > >> > > > > - A2DP
> > >> > > > > - AVRCP
> > >> > > > > - HFP/HSP
> > >> > > > > - HID
> > >> > > > > - LE Mesh
> > >> > > > > - LE Audio
> > >> > > > > - Additional profile-level interoperability logic
> > >> > > > >
> > >> > > > >
> > >> > > > But most of these profiles should belong to the userspace,
> please
> > >> split
> > >> > > the
> > >> > > > related code to nuttx-apps.git, instead nuttx/.
> > >> > > > especially, the code related shell spread in the whole code
> base:
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > >> > > > it's definitely wrong to put the shell code inside kernel space.
> > >> > > >
> > >> > > >
> > >> > > > > The Zephyr Bluetooth stack already provides a broad and
> actively
> > >> > > > maintained
> > >> > > > > implementation across many of these areas. Rebuilding
> equivalent
> > >> > > > > functionality directly on top of the current NuttX Bluetooth
> > stack
> > >> > > would
> > >> > > > > require a very large multi-year effort, including not only
> > >> protocol
> > >> > > > > implementation but also interoperability testing with real
> > phones,
> > >> > > > > headsets, speakers, cars, and other commercial devices.
> > >> > > > >
> > >> > > > > Therefore, our goal is not to discard NuttX's existing work
> > >> lightly,
> > >> > > but
> > >> > > > to
> > >> > > > > provide a practical path to make NuttX capable of supporting a
> > >> much
> > >> > > wider
> > >> > > > > Bluetooth feature set in a reasonable time frame.
> > >> > > > > ------------------------------
> > >> > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > >> > > > >
> > >> > > > > Another important discussion point is whether the new
> Bluetooth
> > >> stack
> > >> > > > > should live in nuttx-apps, similar to how NimBLE is currently
> > >> > > integrated.
> > >> > > > >
> > >> > > > > Our concern is that a host stack is not just an
> > application-level
> > >> > > > > component. It interacts closely with:
> > >> > > > >
> > >> > > > > - HCI transport
> > >> > > > > - L2CAP channels
> > >> > > > > - Socket or device interfaces
> > >> > > > > - Memory pools
> > >> > > > > - Timers and work queues
> > >> > > > > - Security and pairing state
> > >> > > > > - Profile registration
> > >> > > > > - Controller event dispatch
> > >> > > > > - Future kernel/user boundary mechanisms
> > >> > > > >
> > >> > > > > Putting the core host stack in nuttx-apps would either require
> > >> > exposing
> > >> > > > > many internal kernel interfaces or would force the
> > >> application-side
> > >> > > stack
> > >> > > > > to depend on non-public NuttX internals.
> > >> > > > >
> > >> > > > > We already have a similar problem with the current NimBLE
> > >> > integration.
> > >> > > > The
> > >> > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > >> > > kernel/internal
> > >> > > > > APIs. As a result, it is difficult to support protected/kernel
> > >> builds
> > >> > > > > cleanly, and it is also hard to keep the port synchronized
> with
> > >> > > upstream
> > >> > > > > NimBLE over time.
> > >> > > > >
> > >> > > > >
> > >> > > > These are kernel public API, the only problem is that they are
> > >> called
> > >> > by
> > >> > > > userspace.
> > >> > > >
> > >> > > >
> > >> > > > > For this reason, we believe the Bluetooth host core belongs in
> > the
> > >> > > NuttX
> > >> > > > > tree. User-facing profiles, tools, shell commands, or demo
> > >> > applications
> > >> > > > can
> > >> > > > > still live outside the core as appropriate, but the
> > >> transport-facing
> > >> > > host
> > >> > > > > stack should have a well-defined place inside NuttX.
> > >> > > > >
> > >> > > > > There is also a performance consideration. In flat build mode,
> > the
> > >> > > > > Bluetooth host stack can run directly on the kernel side
> without
> > >> > > > additional
> > >> > > > > syscall or user/kernel boundary overhead. This is especially
> > >> > important
> > >> > > > for
> > >> > > > > IoT chips with relatively low CPU frequency, where Bluetooth
> > data
> > >> > path
> > >> > > > and
> > >> > > > > profile handling overhead can have a visible impact on
> > throughput,
> > >> > > > latency,
> > >> > > > > and power consumption.
> > >> > > > >
> > >> > > > > At the same time, this does not mean that the final
> architecture
> > >> must
> > >> > > > > remain flat-build-only. A compatible evolution path is to keep
> > the
> > >> > > > > performance-sensitive transport and host core on the kernel
> > side,
> > >> > while
> > >> > > > > gradually moving suitable Bluetooth profile implementations or
> > >> > > > > profile-facing helper layers into libc-visible build paths.
> This
> > >> > allows
> > >> > > > > protected and kernel builds to use proper public interfaces,
> > while
> > >> > > still
> > >> > > > > preserving good performance for flat build and low-end IoT
> > >> platforms.
> > >> > > > >
> > >> > > > > In other words, placing the stack in nuttx gives us a cleaner
> > >> > long-term
> > >> > > > > architecture:
> > >> > > > >
> > >> > > > > - Flat build can get the best performance with minimum
> > >> overhead.
> > >> > > > > - Protected/kernel build can be supported later through
> > proper
> > >> > > public
> > >> > > > > interfaces.
> > >> > > > > - Profile code can be migrated into libc-compatible paths
> > where
> > >> > > > > appropriate.
> > >> > > > > - Userspace does not need to directly depend on private
> > kernel
> > >> > > > symbols.
> > >> > > > > - The design avoids repeating the long-term maintainability
> > >> issue
> > >> > > seen
> > >> > > > > in some existing userspace Bluetooth integrations.
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > > But Zephyr bluetooth stack is implemented as a monolithic block
> > like
> > >> > > > NimBLE.
> > >> > > > Your current porting just include:
> > >> > > >
> > >> > > > 1. Switch Zephyr API to NuttX kernel API
> > >> > > > 2. Format the code base to follow The NuttX coding style
> > >> > > >
> > >> > > > No any change related to the kernel/user space separation, so
> it's
> > >> > better
> > >> > > > to contain in nuttx-apps.git in the current stage.
> > >> > > > I would suggest you put the initial code inside nuttx-apps and
> > move
> > >> the
> > >> > > > part which belongs to the kernel step by step,
> > >> > > > so the community can review the change more carefully.
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi, raiden
First, we are not using NimBLE — we are using the zblue stack from
openvela/Xiaomi, which has a different architecture and different
performance characteristics than NimBLE. Please don't conflate the two.
Regarding your skepticism about the SPP bandwidth example: have you ever
worked with BLE chips used in LED lighting products? This is a massive
category in smart home. Let me give you a concrete example.
We previously worked with a Chinese chip vendor called Onmicro. Their BLE
SoC uses a Cortex-M0 core at 80 MHz, with only 64 KB flash and 64 KB RAM.
On this platform, just fitting NuttX itself is a challenge, let alone
running a full-featured Bluetooth stack. To support this chip and maximize
HCI throughput, we introduced the btdrv layer in the NuttX stack — a recv
hook that delivers HCI data directly from the controller to the host stack,
bypassing the VFS entirely.
Let me break down the alternative path that we specifically avoided for
this chip:
Controller IRQ → btdrv → VFS → host stack
This path requires two thread context switches and two memory copies on
every HCI packet. On an 80 MHz Cortex-M0, that's not negligible — it's the
difference between the stack being usable or not.
For more capable chips, we still use the standard VFS-based approach — the
btdrv direct path is only enabled on resource-constrained platforms. So
this optimization doesn't affect richer platforms at all.
I'm curious: what would your solution be for a chip like this — 80 MHz M0,
64 KB flash, 64 KB RAM, needing to run both NuttX and a Bluetooth stack?
By the way, you're a Xiaomi contractor — you can ask Xiaoxiang on Lark
directly whether what I'm saying is accurate. He's familiar with the full
details of this project.
raiden00pl <ra...@gmail.com> 于2026年10月16日周五 15:07写道：
> Also, if you’re talking about performance, it would be appropriate to back
> that up with some real data.
>
> From your PR:
>
> > with CPU frequencies below 100 MHz — this copying becomes very costly.
> For example, with SPP bandwidth at 200 MB/s, this alone can consume more
> than 15% CPU load.
>
> This is total nonsense. SPP can't achieve 200 MB/s, it is impossible !
>
> Sorry, but your claims regarding Nimble were simply false, furthermore, the
> example you provided abot SSP is also nonsense. I don’t like that.
>
> pt., 16 paź 2026 o 08:55 raiden00pl <ra...@gmail.com> napisał(a):
>
> > Your response has nothing to do with my reply to your comment about
> > Nimble.
> > No one is claiming that the porting layer in Nimble is perfect, but it
> > certainly
> > doesn't use the kernel's private API.
> >
> > Good architecture and POSIX compliance are the core values of this
> > project.
> > It has always been this way, and I hope it remains so. For this reason,
> > adding
> > anything to the kernel that sits above the L4–L5 layers of the OSI model
> > is
> > a bad idea and I hope it never happens.
> >
> >
> > pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
> >
> >> Hi raiden00pl,
> >>
> >> Regarding your point about the NimBLE port using the POSIX API — yes, it
> >> uses POSIX, but there are real issues with the current implementation
> that
> >> go beyond just kernel/protected mode support.
> >> 1. ble_npl_hw_enter_critical is not a real critical section
> >>
> >> Look at the NuttX port's implementation:
> >>
> >>
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
> >>
> >> static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> >>
> >> uint32_t ble_npl_hw_enter_critical(void)
> >> {
> >> pthread_mutex_lock(&s_mutex);
> >> return 0;
> >> }
> >>
> >> This is a mutex, not a critical section. It does not disable interrupts
> or
> >> preemption — an ISR can still fire and corrupt data that the "critical
> >> section" was supposed to protect. On top of that, using a mutex opens
> the
> >> door to ABBA deadlocks when combined with any other lock held inside the
> >> critical region:
> >>
> >> - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
> >> blocked
> >> by B
> >> - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
> >>
> >> Compare this with the FreeRTOS port, which correctly uses
> >> vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> >> scheduling/preemption). The current NuttX port simply does not meet the
> >> semantic contract that the NimBLE stack expects from
> >> ble_npl_hw_enter_critical.
> >> 2. Time subsystem uses clock_gettime instead of kernel tick APIs
> >>
> >>
> >>
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
> >>
> >> ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...),
> which
> >> involves a syscall and floating-point arithmetic on every call. In a BLE
> >> stack where timestamps and timing are on the hot path, this adds
> >> measurable
> >> overhead compared to accessing the kernel tick counter directly.
> >> 3. Others are already using the kernel approach — and for good reason
> >>
> >> A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> >> uses kernel APIs directly, bypassing POSIX for the performance-critical
> >> paths:
> >>
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> >>
> >> This isn't an academic exercise — it's a production choice. They
> >> recognized
> >> that a BLE stack needs tight integration with the OS timer subsystem,
> >> direct access to critical section primitives, and efficient event
> >> delivery,
> >> none of which POSIX provides well in this context.
> >> My question
> >>
> >> If other organizations are already using a more performant,
> >> architecturally
> >> correct kernel-level integration for their BLE stacks on NuttX, why
> should
> >> we be told that we must use the slower, less correct POSIX path? NuttX's
> >> POSIX compliance is valuable, but it shouldn't come at the cost of
> >> shipping
> >> a BLE stack with a broken critical section primitive. There should be
> room
> >> for both approaches, and the decision should be driven by technical
> merit,
> >> not by treating POSIX as the only acceptable answer.
> >>
> >> Best regards,
> >>
> >> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
> >>
> >> > > We already have a similar problem with the current NimBLE
> integration.
> >> > The
> >> > > NimBLE port in nuttx-apps directly depends on many NuttX
> >> kernel/internal
> >> > > APIs. As a result, it is difficult to support protected/kernel
> builds
> >> > > cleanly, and it is also hard to keep the port synchronized with
> >> upstream
> >> > > NimBLE over time.
> >> >
> >> > Is this an AI analysis or something? Because it’s definitely not true:
> >> > Nimble
> >> > port uses the POSIX API. The only issue with kernel mode is that
> >> > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> >> > limitation,
> >> > not a port architecture issue.
> >> > I agree that synchronizing with an external repository is a challenge.
> >> > However,
> >> > a plus side is that we aren't the ones maintaining the code that must
> >> > comply
> >> > with the BLE standard.
> >> >
> >> > I also consider placing the entire BLE stack within the kernel to be a
> >> bad
> >> > idea.
> >> > Even if performance isn't ideal, it’s the price one pays for a sound
> >> > architecture.
> >> > NuttX has always focused on addressing architectural challenges (POSIX
> >> > compliance)
> >> > rather than striving to be the best in terms of performance.
> >> >
> >> >
> >> > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
> >> >
> >> > > No, I do not agree that the current port is only a Zephyr API
> >> replacement
> >> > > and
> >> > > NuttX coding-style reformatting.
> >> > >
> >> > >
> >> > >
> >> > > This code base has already fixed part of the issues that still exist
> >> in
> >> > the
> >> > >
> >> > > Zephyr community implementation. In addition, we still have pending
> >> > > features and
> >> > > fixes that have not been submitted yet. Since some of those changes
> >> were
> >> > > made by
> >> > > other developers, I cannot submit their work by myself without
> proper
> >> > > permission
> >> > > and attribution.
> >> > >
> >> > >
> >> > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> >> > >
> >> > >
> >> > > I have already stated in the email why I do not recommend putting
> the
> >> > > initial
> >> > > Bluetooth host stack into nuttx-apps. Architecturally, placing it in
> >> apps
> >> > > would
> >> > > cause significant performance degradation compared with the Zephyr
> >> > design.
> >> > > The
> >> > > Bluetooth host stack is tightly coupled with kernel primitives,
> buffer
> >> > >
> >> > > management, work queues, timing, and HCI/driver paths. Moving it
> >> entirely
> >> > > to
> >> > > apps would change that integration model and make the architecture
> >> worse
> >> > > from
> >> > > the beginning.
> >> > >
> >> > >
> >> > >
> >> > > Therefore, please read my previous email more carefully. The concern
> >> here
> >> > > is not
> >> > > only the initial review size, but also the long-term architecture
> and
> >> > > runtime
> >> > > performance of the Bluetooth stack in NuttX.
> >> > >
> >> > > BRs,
> >> > >
> >> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> >> > >
> >> > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com>
> >> wrote:
> >> > > >
> >> > > > > Hi all,
> >> > > > >
> >> > > > > I would like to summarize the background, technical motivation,
> >> and
> >> > > > > proposed evolution plan for PR #20686, which introduces a
> >> > Zephyr-based
> >> > > > > Bluetooth host stack under net/bt.
> >> > > > >
> >> > > > > https://github.com/apache/nuttx/pull/20686
> >> > > > >
> >> > > > > First of all, I fully understand the concerns raised in the
> >> > discussion.
> >> > > > > Adding a new Bluetooth stack is a significant architectural
> >> change,
> >> > and
> >> > > > it
> >> > > > > is reasonable for the community to ask whether we should instead
> >> > > continue
> >> > > > > improving the existing NuttX Bluetooth implementation. I would
> >> like
> >> > to
> >> > > > > explain why we believe introducing the new stack incrementally
> is
> >> the
> >> > > > more
> >> > > > > practical path, while still keeping the long-term NuttX
> >> architecture
> >> > > > clean
> >> > > > > and maintainable.
> >> > > > > ------------------------------
> >> > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> >> > > > >
> >> > > > > The existing NuttX Bluetooth implementation is mainly focused on
> >> BLE
> >> > > > > functionality. However, modern Bluetooth support is no longer
> >> limited
> >> > > to
> >> > > > > basic BLE. A complete Bluetooth host stack now commonly
> includes:
> >> > > > >
> >> > > > > - BLE GAP/GATT/ATT/SMP
> >> > > > > - Classic Bluetooth profiles
> >> > > > > - A2DP
> >> > > > > - AVRCP
> >> > > > > - HFP/HSP
> >> > > > > - HID
> >> > > > > - LE Mesh
> >> > > > > - LE Audio
> >> > > > > - Additional profile-level interoperability logic
> >> > > > >
> >> > > > >
> >> > > > But most of these profiles should belong to the userspace, please
> >> split
> >> > > the
> >> > > > related code to nuttx-apps.git, instead nuttx/.
> >> > > > especially, the code related shell spread in the whole code base:
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> >> > > > it's definitely wrong to put the shell code inside kernel space.
> >> > > >
> >> > > >
> >> > > > > The Zephyr Bluetooth stack already provides a broad and actively
> >> > > > maintained
> >> > > > > implementation across many of these areas. Rebuilding equivalent
> >> > > > > functionality directly on top of the current NuttX Bluetooth
> stack
> >> > > would
> >> > > > > require a very large multi-year effort, including not only
> >> protocol
> >> > > > > implementation but also interoperability testing with real
> phones,
> >> > > > > headsets, speakers, cars, and other commercial devices.
> >> > > > >
> >> > > > > Therefore, our goal is not to discard NuttX's existing work
> >> lightly,
> >> > > but
> >> > > > to
> >> > > > > provide a practical path to make NuttX capable of supporting a
> >> much
> >> > > wider
> >> > > > > Bluetooth feature set in a reasonable time frame.
> >> > > > > ------------------------------
> >> > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> >> > > > >
> >> > > > > Another important discussion point is whether the new Bluetooth
> >> stack
> >> > > > > should live in nuttx-apps, similar to how NimBLE is currently
> >> > > integrated.
> >> > > > >
> >> > > > > Our concern is that a host stack is not just an
> application-level
> >> > > > > component. It interacts closely with:
> >> > > > >
> >> > > > > - HCI transport
> >> > > > > - L2CAP channels
> >> > > > > - Socket or device interfaces
> >> > > > > - Memory pools
> >> > > > > - Timers and work queues
> >> > > > > - Security and pairing state
> >> > > > > - Profile registration
> >> > > > > - Controller event dispatch
> >> > > > > - Future kernel/user boundary mechanisms
> >> > > > >
> >> > > > > Putting the core host stack in nuttx-apps would either require
> >> > exposing
> >> > > > > many internal kernel interfaces or would force the
> >> application-side
> >> > > stack
> >> > > > > to depend on non-public NuttX internals.
> >> > > > >
> >> > > > > We already have a similar problem with the current NimBLE
> >> > integration.
> >> > > > The
> >> > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> >> > > kernel/internal
> >> > > > > APIs. As a result, it is difficult to support protected/kernel
> >> builds
> >> > > > > cleanly, and it is also hard to keep the port synchronized with
> >> > > upstream
> >> > > > > NimBLE over time.
> >> > > > >
> >> > > > >
> >> > > > These are kernel public API, the only problem is that they are
> >> called
> >> > by
> >> > > > userspace.
> >> > > >
> >> > > >
> >> > > > > For this reason, we believe the Bluetooth host core belongs in
> the
> >> > > NuttX
> >> > > > > tree. User-facing profiles, tools, shell commands, or demo
> >> > applications
> >> > > > can
> >> > > > > still live outside the core as appropriate, but the
> >> transport-facing
> >> > > host
> >> > > > > stack should have a well-defined place inside NuttX.
> >> > > > >
> >> > > > > There is also a performance consideration. In flat build mode,
> the
> >> > > > > Bluetooth host stack can run directly on the kernel side without
> >> > > > additional
> >> > > > > syscall or user/kernel boundary overhead. This is especially
> >> > important
> >> > > > for
> >> > > > > IoT chips with relatively low CPU frequency, where Bluetooth
> data
> >> > path
> >> > > > and
> >> > > > > profile handling overhead can have a visible impact on
> throughput,
> >> > > > latency,
> >> > > > > and power consumption.
> >> > > > >
> >> > > > > At the same time, this does not mean that the final architecture
> >> must
> >> > > > > remain flat-build-only. A compatible evolution path is to keep
> the
> >> > > > > performance-sensitive transport and host core on the kernel
> side,
> >> > while
> >> > > > > gradually moving suitable Bluetooth profile implementations or
> >> > > > > profile-facing helper layers into libc-visible build paths. This
> >> > allows
> >> > > > > protected and kernel builds to use proper public interfaces,
> while
> >> > > still
> >> > > > > preserving good performance for flat build and low-end IoT
> >> platforms.
> >> > > > >
> >> > > > > In other words, placing the stack in nuttx gives us a cleaner
> >> > long-term
> >> > > > > architecture:
> >> > > > >
> >> > > > > - Flat build can get the best performance with minimum
> >> overhead.
> >> > > > > - Protected/kernel build can be supported later through
> proper
> >> > > public
> >> > > > > interfaces.
> >> > > > > - Profile code can be migrated into libc-compatible paths
> where
> >> > > > > appropriate.
> >> > > > > - Userspace does not need to directly depend on private
> kernel
> >> > > > symbols.
> >> > > > > - The design avoids repeating the long-term maintainability
> >> issue
> >> > > seen
> >> > > > > in some existing userspace Bluetooth integrations.
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > But Zephyr bluetooth stack is implemented as a monolithic block
> like
> >> > > > NimBLE.
> >> > > > Your current porting just include:
> >> > > >
> >> > > > 1. Switch Zephyr API to NuttX kernel API
> >> > > > 2. Format the code base to follow The NuttX coding style
> >> > > >
> >> > > > No any change related to the kernel/user space separation, so it's
> >> > better
> >> > > > to contain in nuttx-apps.git in the current stage.
> >> > > > I would suggest you put the initial code inside nuttx-apps and
> move
> >> the
> >> > > > part which belongs to the kernel step by step,
> >> > > > so the community can review the change more carefully.
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by raiden00pl <ra...@gmail.com>.
Also, if you’re talking about performance, it would be appropriate to back
that up with some real data.
From your PR:
> with CPU frequencies below 100 MHz — this copying becomes very costly.
For example, with SPP bandwidth at 200 MB/s, this alone can consume more
than 15% CPU load.
This is total nonsense. SPP can't achieve 200 MB/s, it is impossible !
Sorry, but your claims regarding Nimble were simply false, furthermore, the
example you provided abot SSP is also nonsense. I don’t like that.
pt., 16 paź 2026 o 08:55 raiden00pl <ra...@gmail.com> napisał(a):
> Your response has nothing to do with my reply to your comment about
> Nimble.
> No one is claiming that the porting layer in Nimble is perfect, but it
> certainly
> doesn't use the kernel's private API.
>
> Good architecture and POSIX compliance are the core values of this
> project.
> It has always been this way, and I hope it remains so. For this reason,
> adding
> anything to the kernel that sits above the L4–L5 layers of the OSI model
> is
> a bad idea and I hope it never happens.
>
>
> pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
>
>> Hi raiden00pl,
>>
>> Regarding your point about the NimBLE port using the POSIX API — yes, it
>> uses POSIX, but there are real issues with the current implementation that
>> go beyond just kernel/protected mode support.
>> 1. ble_npl_hw_enter_critical is not a real critical section
>>
>> Look at the NuttX port's implementation:
>>
>> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
>>
>> static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>>
>> uint32_t ble_npl_hw_enter_critical(void)
>> {
>> pthread_mutex_lock(&s_mutex);
>> return 0;
>> }
>>
>> This is a mutex, not a critical section. It does not disable interrupts or
>> preemption — an ISR can still fire and corrupt data that the "critical
>> section" was supposed to protect. On top of that, using a mutex opens the
>> door to ABBA deadlocks when combined with any other lock held inside the
>> critical region:
>>
>> - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ←
>> blocked
>> by B
>> - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
>>
>> Compare this with the FreeRTOS port, which correctly uses
>> vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
>> scheduling/preemption). The current NuttX port simply does not meet the
>> semantic contract that the NimBLE stack expects from
>> ble_npl_hw_enter_critical.
>> 2. Time subsystem uses clock_gettime instead of kernel tick APIs
>>
>>
>> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
>>
>> ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...), which
>> involves a syscall and floating-point arithmetic on every call. In a BLE
>> stack where timestamps and timing are on the hot path, this adds
>> measurable
>> overhead compared to accessing the kernel tick counter directly.
>> 3. Others are already using the kernel approach — and for good reason
>>
>> A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
>> uses kernel APIs directly, bypassing POSIX for the performance-critical
>> paths:
>> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
>>
>> This isn't an academic exercise — it's a production choice. They
>> recognized
>> that a BLE stack needs tight integration with the OS timer subsystem,
>> direct access to critical section primitives, and efficient event
>> delivery,
>> none of which POSIX provides well in this context.
>> My question
>>
>> If other organizations are already using a more performant,
>> architecturally
>> correct kernel-level integration for their BLE stacks on NuttX, why should
>> we be told that we must use the slower, less correct POSIX path? NuttX's
>> POSIX compliance is valuable, but it shouldn't come at the cost of
>> shipping
>> a BLE stack with a broken critical section primitive. There should be room
>> for both approaches, and the decision should be driven by technical merit,
>> not by treating POSIX as the only acceptable answer.
>>
>> Best regards,
>>
>> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
>>
>> > > We already have a similar problem with the current NimBLE integration.
>> > The
>> > > NimBLE port in nuttx-apps directly depends on many NuttX
>> kernel/internal
>> > > APIs. As a result, it is difficult to support protected/kernel builds
>> > > cleanly, and it is also hard to keep the port synchronized with
>> upstream
>> > > NimBLE over time.
>> >
>> > Is this an AI analysis or something? Because it’s definitely not true:
>> > Nimble
>> > port uses the POSIX API. The only issue with kernel mode is that
>> > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
>> > limitation,
>> > not a port architecture issue.
>> > I agree that synchronizing with an external repository is a challenge.
>> > However,
>> > a plus side is that we aren't the ones maintaining the code that must
>> > comply
>> > with the BLE standard.
>> >
>> > I also consider placing the entire BLE stack within the kernel to be a
>> bad
>> > idea.
>> > Even if performance isn't ideal, it’s the price one pays for a sound
>> > architecture.
>> > NuttX has always focused on addressing architectural challenges (POSIX
>> > compliance)
>> > rather than striving to be the best in terms of performance.
>> >
>> >
>> > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
>> >
>> > > No, I do not agree that the current port is only a Zephyr API
>> replacement
>> > > and
>> > > NuttX coding-style reformatting.
>> > >
>> > >
>> > >
>> > > This code base has already fixed part of the issues that still exist
>> in
>> > the
>> > >
>> > > Zephyr community implementation. In addition, we still have pending
>> > > features and
>> > > fixes that have not been submitted yet. Since some of those changes
>> were
>> > > made by
>> > > other developers, I cannot submit their work by myself without proper
>> > > permission
>> > > and attribution.
>> > >
>> > >
>> > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
>> > >
>> > >
>> > > I have already stated in the email why I do not recommend putting the
>> > > initial
>> > > Bluetooth host stack into nuttx-apps. Architecturally, placing it in
>> apps
>> > > would
>> > > cause significant performance degradation compared with the Zephyr
>> > design.
>> > > The
>> > > Bluetooth host stack is tightly coupled with kernel primitives, buffer
>> > >
>> > > management, work queues, timing, and HCI/driver paths. Moving it
>> entirely
>> > > to
>> > > apps would change that integration model and make the architecture
>> worse
>> > > from
>> > > the beginning.
>> > >
>> > >
>> > >
>> > > Therefore, please read my previous email more carefully. The concern
>> here
>> > > is not
>> > > only the initial review size, but also the long-term architecture and
>> > > runtime
>> > > performance of the Bluetooth stack in NuttX.
>> > >
>> > > BRs,
>> > >
>> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
>> > >
>> > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com>
>> wrote:
>> > > >
>> > > > > Hi all,
>> > > > >
>> > > > > I would like to summarize the background, technical motivation,
>> and
>> > > > > proposed evolution plan for PR #20686, which introduces a
>> > Zephyr-based
>> > > > > Bluetooth host stack under net/bt.
>> > > > >
>> > > > > https://github.com/apache/nuttx/pull/20686
>> > > > >
>> > > > > First of all, I fully understand the concerns raised in the
>> > discussion.
>> > > > > Adding a new Bluetooth stack is a significant architectural
>> change,
>> > and
>> > > > it
>> > > > > is reasonable for the community to ask whether we should instead
>> > > continue
>> > > > > improving the existing NuttX Bluetooth implementation. I would
>> like
>> > to
>> > > > > explain why we believe introducing the new stack incrementally is
>> the
>> > > > more
>> > > > > practical path, while still keeping the long-term NuttX
>> architecture
>> > > > clean
>> > > > > and maintainable.
>> > > > > ------------------------------
>> > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
>> > > > >
>> > > > > The existing NuttX Bluetooth implementation is mainly focused on
>> BLE
>> > > > > functionality. However, modern Bluetooth support is no longer
>> limited
>> > > to
>> > > > > basic BLE. A complete Bluetooth host stack now commonly includes:
>> > > > >
>> > > > > - BLE GAP/GATT/ATT/SMP
>> > > > > - Classic Bluetooth profiles
>> > > > > - A2DP
>> > > > > - AVRCP
>> > > > > - HFP/HSP
>> > > > > - HID
>> > > > > - LE Mesh
>> > > > > - LE Audio
>> > > > > - Additional profile-level interoperability logic
>> > > > >
>> > > > >
>> > > > But most of these profiles should belong to the userspace, please
>> split
>> > > the
>> > > > related code to nuttx-apps.git, instead nuttx/.
>> > > > especially, the code related shell spread in the whole code base:
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
>> > > > it's definitely wrong to put the shell code inside kernel space.
>> > > >
>> > > >
>> > > > > The Zephyr Bluetooth stack already provides a broad and actively
>> > > > maintained
>> > > > > implementation across many of these areas. Rebuilding equivalent
>> > > > > functionality directly on top of the current NuttX Bluetooth stack
>> > > would
>> > > > > require a very large multi-year effort, including not only
>> protocol
>> > > > > implementation but also interoperability testing with real phones,
>> > > > > headsets, speakers, cars, and other commercial devices.
>> > > > >
>> > > > > Therefore, our goal is not to discard NuttX's existing work
>> lightly,
>> > > but
>> > > > to
>> > > > > provide a practical path to make NuttX capable of supporting a
>> much
>> > > wider
>> > > > > Bluetooth feature set in a reasonable time frame.
>> > > > > ------------------------------
>> > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
>> > > > >
>> > > > > Another important discussion point is whether the new Bluetooth
>> stack
>> > > > > should live in nuttx-apps, similar to how NimBLE is currently
>> > > integrated.
>> > > > >
>> > > > > Our concern is that a host stack is not just an application-level
>> > > > > component. It interacts closely with:
>> > > > >
>> > > > > - HCI transport
>> > > > > - L2CAP channels
>> > > > > - Socket or device interfaces
>> > > > > - Memory pools
>> > > > > - Timers and work queues
>> > > > > - Security and pairing state
>> > > > > - Profile registration
>> > > > > - Controller event dispatch
>> > > > > - Future kernel/user boundary mechanisms
>> > > > >
>> > > > > Putting the core host stack in nuttx-apps would either require
>> > exposing
>> > > > > many internal kernel interfaces or would force the
>> application-side
>> > > stack
>> > > > > to depend on non-public NuttX internals.
>> > > > >
>> > > > > We already have a similar problem with the current NimBLE
>> > integration.
>> > > > The
>> > > > > NimBLE port in nuttx-apps directly depends on many NuttX
>> > > kernel/internal
>> > > > > APIs. As a result, it is difficult to support protected/kernel
>> builds
>> > > > > cleanly, and it is also hard to keep the port synchronized with
>> > > upstream
>> > > > > NimBLE over time.
>> > > > >
>> > > > >
>> > > > These are kernel public API, the only problem is that they are
>> called
>> > by
>> > > > userspace.
>> > > >
>> > > >
>> > > > > For this reason, we believe the Bluetooth host core belongs in the
>> > > NuttX
>> > > > > tree. User-facing profiles, tools, shell commands, or demo
>> > applications
>> > > > can
>> > > > > still live outside the core as appropriate, but the
>> transport-facing
>> > > host
>> > > > > stack should have a well-defined place inside NuttX.
>> > > > >
>> > > > > There is also a performance consideration. In flat build mode, the
>> > > > > Bluetooth host stack can run directly on the kernel side without
>> > > > additional
>> > > > > syscall or user/kernel boundary overhead. This is especially
>> > important
>> > > > for
>> > > > > IoT chips with relatively low CPU frequency, where Bluetooth data
>> > path
>> > > > and
>> > > > > profile handling overhead can have a visible impact on throughput,
>> > > > latency,
>> > > > > and power consumption.
>> > > > >
>> > > > > At the same time, this does not mean that the final architecture
>> must
>> > > > > remain flat-build-only. A compatible evolution path is to keep the
>> > > > > performance-sensitive transport and host core on the kernel side,
>> > while
>> > > > > gradually moving suitable Bluetooth profile implementations or
>> > > > > profile-facing helper layers into libc-visible build paths. This
>> > allows
>> > > > > protected and kernel builds to use proper public interfaces, while
>> > > still
>> > > > > preserving good performance for flat build and low-end IoT
>> platforms.
>> > > > >
>> > > > > In other words, placing the stack in nuttx gives us a cleaner
>> > long-term
>> > > > > architecture:
>> > > > >
>> > > > > - Flat build can get the best performance with minimum
>> overhead.
>> > > > > - Protected/kernel build can be supported later through proper
>> > > public
>> > > > > interfaces.
>> > > > > - Profile code can be migrated into libc-compatible paths where
>> > > > > appropriate.
>> > > > > - Userspace does not need to directly depend on private kernel
>> > > > symbols.
>> > > > > - The design avoids repeating the long-term maintainability
>> issue
>> > > seen
>> > > > > in some existing userspace Bluetooth integrations.
>> > > > >
>> > > > >
>> > > >
>> > > > But Zephyr bluetooth stack is implemented as a monolithic block like
>> > > > NimBLE.
>> > > > Your current porting just include:
>> > > >
>> > > > 1. Switch Zephyr API to NuttX kernel API
>> > > > 2. Format the code base to follow The NuttX coding style
>> > > >
>> > > > No any change related to the kernel/user space separation, so it's
>> > better
>> > > > to contain in nuttx-apps.git in the current stage.
>> > > > I would suggest you put the initial code inside nuttx-apps and move
>> the
>> > > > part which belongs to the kernel step by step,
>> > > > so the community can review the change more carefully.
>> > > >
>> > >
>> >
>>
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by raiden00pl <ra...@gmail.com>.
Your response has nothing to do with my reply to your comment about Nimble.
No one is claiming that the porting layer in Nimble is perfect, but it
certainly
doesn't use the kernel's private API.
Good architecture and POSIX compliance are the core values of this project.
It has always been this way, and I hope it remains so. For this reason,
adding
anything to the kernel that sits above the L4–L5 layers of the OSI model is
a bad idea and I hope it never happens.
pt., 16 paź 2026 o 08:44 chao an <ma...@gmail.com> napisał(a):
> Hi raiden00pl,
>
> Regarding your point about the NimBLE port using the POSIX API — yes, it
> uses POSIX, but there are real issues with the current implementation that
> go beyond just kernel/protected mode support.
> 1. ble_npl_hw_enter_critical is not a real critical section
>
> Look at the NuttX port's implementation:
>
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
>
> static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>
> uint32_t ble_npl_hw_enter_critical(void)
> {
> pthread_mutex_lock(&s_mutex);
> return 0;
> }
>
> This is a mutex, not a critical section. It does not disable interrupts or
> preemption — an ISR can still fire and corrupt data that the "critical
> section" was supposed to protect. On top of that, using a mutex opens the
> door to ABBA deadlocks when combined with any other lock held inside the
> critical region:
>
> - Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ← blocked
> by B
> - Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
>
> Compare this with the FreeRTOS port, which correctly uses
> vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
> scheduling/preemption). The current NuttX port simply does not meet the
> semantic contract that the NimBLE stack expects from
> ble_npl_hw_enter_critical.
> 2. Time subsystem uses clock_gettime instead of kernel tick APIs
>
>
> https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
>
> ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...), which
> involves a syscall and floating-point arithmetic on every call. In a BLE
> stack where timestamps and timing are on the hot path, this adds measurable
> overhead compared to accessing the kernel tick counter directly.
> 3. Others are already using the kernel approach — and for good reason
>
> A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
> uses kernel APIs directly, bypassing POSIX for the performance-critical
> paths:
> https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
>
> This isn't an academic exercise — it's a production choice. They recognized
> that a BLE stack needs tight integration with the OS timer subsystem,
> direct access to critical section primitives, and efficient event delivery,
> none of which POSIX provides well in this context.
> My question
>
> If other organizations are already using a more performant, architecturally
> correct kernel-level integration for their BLE stacks on NuttX, why should
> we be told that we must use the slower, less correct POSIX path? NuttX's
> POSIX compliance is valuable, but it shouldn't come at the cost of shipping
> a BLE stack with a broken critical section primitive. There should be room
> for both approaches, and the decision should be driven by technical merit,
> not by treating POSIX as the only acceptable answer.
>
> Best regards,
>
> raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
>
> > > We already have a similar problem with the current NimBLE integration.
> > The
> > > NimBLE port in nuttx-apps directly depends on many NuttX
> kernel/internal
> > > APIs. As a result, it is difficult to support protected/kernel builds
> > > cleanly, and it is also hard to keep the port synchronized with
> upstream
> > > NimBLE over time.
> >
> > Is this an AI analysis or something? Because it’s definitely not true:
> > Nimble
> > port uses the POSIX API. The only issue with kernel mode is that
> > SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> > limitation,
> > not a port architecture issue.
> > I agree that synchronizing with an external repository is a challenge.
> > However,
> > a plus side is that we aren't the ones maintaining the code that must
> > comply
> > with the BLE standard.
> >
> > I also consider placing the entire BLE stack within the kernel to be a
> bad
> > idea.
> > Even if performance isn't ideal, it’s the price one pays for a sound
> > architecture.
> > NuttX has always focused on addressing architectural challenges (POSIX
> > compliance)
> > rather than striving to be the best in terms of performance.
> >
> >
> > pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
> >
> > > No, I do not agree that the current port is only a Zephyr API
> replacement
> > > and
> > > NuttX coding-style reformatting.
> > >
> > >
> > >
> > > This code base has already fixed part of the issues that still exist in
> > the
> > >
> > > Zephyr community implementation. In addition, we still have pending
> > > features and
> > > fixes that have not been submitted yet. Since some of those changes
> were
> > > made by
> > > other developers, I cannot submit their work by myself without proper
> > > permission
> > > and attribution.
> > >
> > >
> > > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> > >
> > >
> > > I have already stated in the email why I do not recommend putting the
> > > initial
> > > Bluetooth host stack into nuttx-apps. Architecturally, placing it in
> apps
> > > would
> > > cause significant performance degradation compared with the Zephyr
> > design.
> > > The
> > > Bluetooth host stack is tightly coupled with kernel primitives, buffer
> > >
> > > management, work queues, timing, and HCI/driver paths. Moving it
> entirely
> > > to
> > > apps would change that integration model and make the architecture
> worse
> > > from
> > > the beginning.
> > >
> > >
> > >
> > > Therefore, please read my previous email more carefully. The concern
> here
> > > is not
> > > only the initial review size, but also the long-term architecture and
> > > runtime
> > > performance of the Bluetooth stack in NuttX.
> > >
> > > BRs,
> > >
> > > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> > >
> > > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com>
> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I would like to summarize the background, technical motivation, and
> > > > > proposed evolution plan for PR #20686, which introduces a
> > Zephyr-based
> > > > > Bluetooth host stack under net/bt.
> > > > >
> > > > > https://github.com/apache/nuttx/pull/20686
> > > > >
> > > > > First of all, I fully understand the concerns raised in the
> > discussion.
> > > > > Adding a new Bluetooth stack is a significant architectural change,
> > and
> > > > it
> > > > > is reasonable for the community to ask whether we should instead
> > > continue
> > > > > improving the existing NuttX Bluetooth implementation. I would like
> > to
> > > > > explain why we believe introducing the new stack incrementally is
> the
> > > > more
> > > > > practical path, while still keeping the long-term NuttX
> architecture
> > > > clean
> > > > > and maintainable.
> > > > > ------------------------------
> > > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > > > >
> > > > > The existing NuttX Bluetooth implementation is mainly focused on
> BLE
> > > > > functionality. However, modern Bluetooth support is no longer
> limited
> > > to
> > > > > basic BLE. A complete Bluetooth host stack now commonly includes:
> > > > >
> > > > > - BLE GAP/GATT/ATT/SMP
> > > > > - Classic Bluetooth profiles
> > > > > - A2DP
> > > > > - AVRCP
> > > > > - HFP/HSP
> > > > > - HID
> > > > > - LE Mesh
> > > > > - LE Audio
> > > > > - Additional profile-level interoperability logic
> > > > >
> > > > >
> > > > But most of these profiles should belong to the userspace, please
> split
> > > the
> > > > related code to nuttx-apps.git, instead nuttx/.
> > > > especially, the code related shell spread in the whole code base:
> > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> > > >
> > > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > > > it's definitely wrong to put the shell code inside kernel space.
> > > >
> > > >
> > > > > The Zephyr Bluetooth stack already provides a broad and actively
> > > > maintained
> > > > > implementation across many of these areas. Rebuilding equivalent
> > > > > functionality directly on top of the current NuttX Bluetooth stack
> > > would
> > > > > require a very large multi-year effort, including not only protocol
> > > > > implementation but also interoperability testing with real phones,
> > > > > headsets, speakers, cars, and other commercial devices.
> > > > >
> > > > > Therefore, our goal is not to discard NuttX's existing work
> lightly,
> > > but
> > > > to
> > > > > provide a practical path to make NuttX capable of supporting a much
> > > wider
> > > > > Bluetooth feature set in a reasonable time frame.
> > > > > ------------------------------
> > > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > > > >
> > > > > Another important discussion point is whether the new Bluetooth
> stack
> > > > > should live in nuttx-apps, similar to how NimBLE is currently
> > > integrated.
> > > > >
> > > > > Our concern is that a host stack is not just an application-level
> > > > > component. It interacts closely with:
> > > > >
> > > > > - HCI transport
> > > > > - L2CAP channels
> > > > > - Socket or device interfaces
> > > > > - Memory pools
> > > > > - Timers and work queues
> > > > > - Security and pairing state
> > > > > - Profile registration
> > > > > - Controller event dispatch
> > > > > - Future kernel/user boundary mechanisms
> > > > >
> > > > > Putting the core host stack in nuttx-apps would either require
> > exposing
> > > > > many internal kernel interfaces or would force the application-side
> > > stack
> > > > > to depend on non-public NuttX internals.
> > > > >
> > > > > We already have a similar problem with the current NimBLE
> > integration.
> > > > The
> > > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > > kernel/internal
> > > > > APIs. As a result, it is difficult to support protected/kernel
> builds
> > > > > cleanly, and it is also hard to keep the port synchronized with
> > > upstream
> > > > > NimBLE over time.
> > > > >
> > > > >
> > > > These are kernel public API, the only problem is that they are called
> > by
> > > > userspace.
> > > >
> > > >
> > > > > For this reason, we believe the Bluetooth host core belongs in the
> > > NuttX
> > > > > tree. User-facing profiles, tools, shell commands, or demo
> > applications
> > > > can
> > > > > still live outside the core as appropriate, but the
> transport-facing
> > > host
> > > > > stack should have a well-defined place inside NuttX.
> > > > >
> > > > > There is also a performance consideration. In flat build mode, the
> > > > > Bluetooth host stack can run directly on the kernel side without
> > > > additional
> > > > > syscall or user/kernel boundary overhead. This is especially
> > important
> > > > for
> > > > > IoT chips with relatively low CPU frequency, where Bluetooth data
> > path
> > > > and
> > > > > profile handling overhead can have a visible impact on throughput,
> > > > latency,
> > > > > and power consumption.
> > > > >
> > > > > At the same time, this does not mean that the final architecture
> must
> > > > > remain flat-build-only. A compatible evolution path is to keep the
> > > > > performance-sensitive transport and host core on the kernel side,
> > while
> > > > > gradually moving suitable Bluetooth profile implementations or
> > > > > profile-facing helper layers into libc-visible build paths. This
> > allows
> > > > > protected and kernel builds to use proper public interfaces, while
> > > still
> > > > > preserving good performance for flat build and low-end IoT
> platforms.
> > > > >
> > > > > In other words, placing the stack in nuttx gives us a cleaner
> > long-term
> > > > > architecture:
> > > > >
> > > > > - Flat build can get the best performance with minimum overhead.
> > > > > - Protected/kernel build can be supported later through proper
> > > public
> > > > > interfaces.
> > > > > - Profile code can be migrated into libc-compatible paths where
> > > > > appropriate.
> > > > > - Userspace does not need to directly depend on private kernel
> > > > symbols.
> > > > > - The design avoids repeating the long-term maintainability
> issue
> > > seen
> > > > > in some existing userspace Bluetooth integrations.
> > > > >
> > > > >
> > > >
> > > > But Zephyr bluetooth stack is implemented as a monolithic block like
> > > > NimBLE.
> > > > Your current porting just include:
> > > >
> > > > 1. Switch Zephyr API to NuttX kernel API
> > > > 2. Format the code base to follow The NuttX coding style
> > > >
> > > > No any change related to the kernel/user space separation, so it's
> > better
> > > > to contain in nuttx-apps.git in the current stage.
> > > > I would suggest you put the initial code inside nuttx-apps and move
> the
> > > > part which belongs to the kernel step by step,
> > > > so the community can review the change more carefully.
> > > >
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
Hi raiden00pl,
Regarding your point about the NimBLE port using the POSIX API — yes, it
uses POSIX, but there are real issues with the current implementation that
go beyond just kernel/protected mode support.
1. ble_npl_hw_enter_critical is not a real critical section
Look at the NuttX port's implementation:
https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_atomic.c
static pthread_mutex_t s_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
uint32_t ble_npl_hw_enter_critical(void)
{
pthread_mutex_lock(&s_mutex);
return 0;
}
This is a mutex, not a critical section. It does not disable interrupts or
preemption — an ISR can still fire and corrupt data that the "critical
section" was supposed to protect. On top of that, using a mutex opens the
door to ABBA deadlocks when combined with any other lock held inside the
critical region:
- Thread A: enter_critical → lock(s_mutex) → try lock(mutex M) ← blocked
by B
- Thread B: lock(M) → enter_critical → lock(s_mutex) ← blocked by A
Compare this with the FreeRTOS port, which correctly uses
vPortEnterCritical() / vPortExitCritical() (i.e., actually disabling
scheduling/preemption). The current NuttX port simply does not meet the
semantic contract that the NimBLE stack expects from
ble_npl_hw_enter_critical.
2. Time subsystem uses clock_gettime instead of kernel tick APIs
https://github.com/apache/mynewt-nimble/blob/master/porting/npl/nuttx/src/os_time.c
ble_npl_time_get() is backed by clock_gettime(CLOCK_MONOTONIC, ...), which
involves a syscall and floating-point arithmetic on every call. In a BLE
stack where timestamps and timing are on the hot path, this adds measurable
overhead compared to accessing the kernel tick counter directly.
3. Others are already using the kernel approach — and for good reason
A concrete example: Xiaomi's Bluetooth stack (zblue) for openvela/NuttX
uses kernel APIs directly, bypassing POSIX for the performance-critical
paths:
https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
This isn't an academic exercise — it's a production choice. They recognized
that a BLE stack needs tight integration with the OS timer subsystem,
direct access to critical section primitives, and efficient event delivery,
none of which POSIX provides well in this context.
My question
If other organizations are already using a more performant, architecturally
correct kernel-level integration for their BLE stacks on NuttX, why should
we be told that we must use the slower, less correct POSIX path? NuttX's
POSIX compliance is valuable, but it shouldn't come at the cost of shipping
a BLE stack with a broken critical section primitive. There should be room
for both approaches, and the decision should be driven by technical merit,
not by treating POSIX as the only acceptable answer.
Best regards,
raiden00pl <ra...@gmail.com> 于2026年10月16日周五 14:06写道：
> > We already have a similar problem with the current NimBLE integration.
> The
> > NimBLE port in nuttx-apps directly depends on many NuttX kernel/internal
> > APIs. As a result, it is difficult to support protected/kernel builds
> > cleanly, and it is also hard to keep the port synchronized with upstream
> > NimBLE over time.
>
> Is this an AI analysis or something? Because it’s definitely not true:
> Nimble
> port uses the POSIX API. The only issue with kernel mode is that
> SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
> limitation,
> not a port architecture issue.
> I agree that synchronizing with an external repository is a challenge.
> However,
> a plus side is that we aren't the ones maintaining the code that must
> comply
> with the BLE standard.
>
> I also consider placing the entire BLE stack within the kernel to be a bad
> idea.
> Even if performance isn't ideal, it’s the price one pays for a sound
> architecture.
> NuttX has always focused on addressing architectural challenges (POSIX
> compliance)
> rather than striving to be the best in terms of performance.
>
>
> pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
>
> > No, I do not agree that the current port is only a Zephyr API replacement
> > and
> > NuttX coding-style reformatting.
> >
> >
> >
> > This code base has already fixed part of the issues that still exist in
> the
> >
> > Zephyr community implementation. In addition, we still have pending
> > features and
> > fixes that have not been submitted yet. Since some of those changes were
> > made by
> > other developers, I cannot submit their work by myself without proper
> > permission
> > and attribution.
> >
> >
> > https://github.com/zephyrproject-rtos/zephyr/pull/122348
> >
> >
> > I have already stated in the email why I do not recommend putting the
> > initial
> > Bluetooth host stack into nuttx-apps. Architecturally, placing it in apps
> > would
> > cause significant performance degradation compared with the Zephyr
> design.
> > The
> > Bluetooth host stack is tightly coupled with kernel primitives, buffer
> >
> > management, work queues, timing, and HCI/driver paths. Moving it entirely
> > to
> > apps would change that integration model and make the architecture worse
> > from
> > the beginning.
> >
> >
> >
> > Therefore, please read my previous email more carefully. The concern here
> > is not
> > only the initial review size, but also the long-term architecture and
> > runtime
> > performance of the Bluetooth stack in NuttX.
> >
> > BRs,
> >
> > Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> >
> > > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I would like to summarize the background, technical motivation, and
> > > > proposed evolution plan for PR #20686, which introduces a
> Zephyr-based
> > > > Bluetooth host stack under net/bt.
> > > >
> > > > https://github.com/apache/nuttx/pull/20686
> > > >
> > > > First of all, I fully understand the concerns raised in the
> discussion.
> > > > Adding a new Bluetooth stack is a significant architectural change,
> and
> > > it
> > > > is reasonable for the community to ask whether we should instead
> > continue
> > > > improving the existing NuttX Bluetooth implementation. I would like
> to
> > > > explain why we believe introducing the new stack incrementally is the
> > > more
> > > > practical path, while still keeping the long-term NuttX architecture
> > > clean
> > > > and maintainable.
> > > > ------------------------------
> > > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > > >
> > > > The existing NuttX Bluetooth implementation is mainly focused on BLE
> > > > functionality. However, modern Bluetooth support is no longer limited
> > to
> > > > basic BLE. A complete Bluetooth host stack now commonly includes:
> > > >
> > > > - BLE GAP/GATT/ATT/SMP
> > > > - Classic Bluetooth profiles
> > > > - A2DP
> > > > - AVRCP
> > > > - HFP/HSP
> > > > - HID
> > > > - LE Mesh
> > > > - LE Audio
> > > > - Additional profile-level interoperability logic
> > > >
> > > >
> > > But most of these profiles should belong to the userspace, please split
> > the
> > > related code to nuttx-apps.git, instead nuttx/.
> > > especially, the code related shell spread in the whole code base:
> > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> > >
> > >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> > >
> > >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > > it's definitely wrong to put the shell code inside kernel space.
> > >
> > >
> > > > The Zephyr Bluetooth stack already provides a broad and actively
> > > maintained
> > > > implementation across many of these areas. Rebuilding equivalent
> > > > functionality directly on top of the current NuttX Bluetooth stack
> > would
> > > > require a very large multi-year effort, including not only protocol
> > > > implementation but also interoperability testing with real phones,
> > > > headsets, speakers, cars, and other commercial devices.
> > > >
> > > > Therefore, our goal is not to discard NuttX's existing work lightly,
> > but
> > > to
> > > > provide a practical path to make NuttX capable of supporting a much
> > wider
> > > > Bluetooth feature set in a reasonable time frame.
> > > > ------------------------------
> > > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > > >
> > > > Another important discussion point is whether the new Bluetooth stack
> > > > should live in nuttx-apps, similar to how NimBLE is currently
> > integrated.
> > > >
> > > > Our concern is that a host stack is not just an application-level
> > > > component. It interacts closely with:
> > > >
> > > > - HCI transport
> > > > - L2CAP channels
> > > > - Socket or device interfaces
> > > > - Memory pools
> > > > - Timers and work queues
> > > > - Security and pairing state
> > > > - Profile registration
> > > > - Controller event dispatch
> > > > - Future kernel/user boundary mechanisms
> > > >
> > > > Putting the core host stack in nuttx-apps would either require
> exposing
> > > > many internal kernel interfaces or would force the application-side
> > stack
> > > > to depend on non-public NuttX internals.
> > > >
> > > > We already have a similar problem with the current NimBLE
> integration.
> > > The
> > > > NimBLE port in nuttx-apps directly depends on many NuttX
> > kernel/internal
> > > > APIs. As a result, it is difficult to support protected/kernel builds
> > > > cleanly, and it is also hard to keep the port synchronized with
> > upstream
> > > > NimBLE over time.
> > > >
> > > >
> > > These are kernel public API, the only problem is that they are called
> by
> > > userspace.
> > >
> > >
> > > > For this reason, we believe the Bluetooth host core belongs in the
> > NuttX
> > > > tree. User-facing profiles, tools, shell commands, or demo
> applications
> > > can
> > > > still live outside the core as appropriate, but the transport-facing
> > host
> > > > stack should have a well-defined place inside NuttX.
> > > >
> > > > There is also a performance consideration. In flat build mode, the
> > > > Bluetooth host stack can run directly on the kernel side without
> > > additional
> > > > syscall or user/kernel boundary overhead. This is especially
> important
> > > for
> > > > IoT chips with relatively low CPU frequency, where Bluetooth data
> path
> > > and
> > > > profile handling overhead can have a visible impact on throughput,
> > > latency,
> > > > and power consumption.
> > > >
> > > > At the same time, this does not mean that the final architecture must
> > > > remain flat-build-only. A compatible evolution path is to keep the
> > > > performance-sensitive transport and host core on the kernel side,
> while
> > > > gradually moving suitable Bluetooth profile implementations or
> > > > profile-facing helper layers into libc-visible build paths. This
> allows
> > > > protected and kernel builds to use proper public interfaces, while
> > still
> > > > preserving good performance for flat build and low-end IoT platforms.
> > > >
> > > > In other words, placing the stack in nuttx gives us a cleaner
> long-term
> > > > architecture:
> > > >
> > > > - Flat build can get the best performance with minimum overhead.
> > > > - Protected/kernel build can be supported later through proper
> > public
> > > > interfaces.
> > > > - Profile code can be migrated into libc-compatible paths where
> > > > appropriate.
> > > > - Userspace does not need to directly depend on private kernel
> > > symbols.
> > > > - The design avoids repeating the long-term maintainability issue
> > seen
> > > > in some existing userspace Bluetooth integrations.
> > > >
> > > >
> > >
> > > But Zephyr bluetooth stack is implemented as a monolithic block like
> > > NimBLE.
> > > Your current porting just include:
> > >
> > > 1. Switch Zephyr API to NuttX kernel API
> > > 2. Format the code base to follow The NuttX coding style
> > >
> > > No any change related to the kernel/user space separation, so it's
> better
> > > to contain in nuttx-apps.git in the current stage.
> > > I would suggest you put the initial code inside nuttx-apps and move the
> > > part which belongs to the kernel step by step,
> > > so the community can review the change more carefully.
> > >
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by raiden00pl <ra...@gmail.com>.
> We already have a similar problem with the current NimBLE integration. The
> NimBLE port in nuttx-apps directly depends on many NuttX kernel/internal
> APIs. As a result, it is difficult to support protected/kernel builds
> cleanly, and it is also hard to keep the port synchronized with upstream
> NimBLE over time.
Is this an AI analysis or something? Because it’s definitely not true:
Nimble
port uses the POSIX API. The only issue with kernel mode is that
SIGEV_SIGNAL is not supported in kernel mode, but this is a nuttx
limitation,
not a port architecture issue.
I agree that synchronizing with an external repository is a challenge.
However,
a plus side is that we aren't the ones maintaining the code that must
comply
with the BLE standard.
I also consider placing the entire BLE stack within the kernel to be a bad
idea.
Even if performance isn't ideal, it’s the price one pays for a sound
architecture.
NuttX has always focused on addressing architectural challenges (POSIX
compliance)
rather than striving to be the best in terms of performance.
pt., 16 paź 2026 o 06:52 chao an <ma...@gmail.com> napisał(a):
> No, I do not agree that the current port is only a Zephyr API replacement
> and
> NuttX coding-style reformatting.
>
>
>
> This code base has already fixed part of the issues that still exist in the
>
> Zephyr community implementation. In addition, we still have pending
> features and
> fixes that have not been submitted yet. Since some of those changes were
> made by
> other developers, I cannot submit their work by myself without proper
> permission
> and attribution.
>
>
> https://github.com/zephyrproject-rtos/zephyr/pull/122348
>
>
> I have already stated in the email why I do not recommend putting the
> initial
> Bluetooth host stack into nuttx-apps. Architecturally, placing it in apps
> would
> cause significant performance degradation compared with the Zephyr design.
> The
> Bluetooth host stack is tightly coupled with kernel primitives, buffer
>
> management, work queues, timing, and HCI/driver paths. Moving it entirely
> to
> apps would change that integration model and make the architecture worse
> from
> the beginning.
>
>
>
> Therefore, please read my previous email more carefully. The concern here
> is not
> only the initial review size, but also the long-term architecture and
> runtime
> performance of the Bluetooth stack in NuttX.
>
> BRs,
>
> Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
>
> > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I would like to summarize the background, technical motivation, and
> > > proposed evolution plan for PR #20686, which introduces a Zephyr-based
> > > Bluetooth host stack under net/bt.
> > >
> > > https://github.com/apache/nuttx/pull/20686
> > >
> > > First of all, I fully understand the concerns raised in the discussion.
> > > Adding a new Bluetooth stack is a significant architectural change, and
> > it
> > > is reasonable for the community to ask whether we should instead
> continue
> > > improving the existing NuttX Bluetooth implementation. I would like to
> > > explain why we believe introducing the new stack incrementally is the
> > more
> > > practical path, while still keeping the long-term NuttX architecture
> > clean
> > > and maintainable.
> > > ------------------------------
> > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > >
> > > The existing NuttX Bluetooth implementation is mainly focused on BLE
> > > functionality. However, modern Bluetooth support is no longer limited
> to
> > > basic BLE. A complete Bluetooth host stack now commonly includes:
> > >
> > > - BLE GAP/GATT/ATT/SMP
> > > - Classic Bluetooth profiles
> > > - A2DP
> > > - AVRCP
> > > - HFP/HSP
> > > - HID
> > > - LE Mesh
> > > - LE Audio
> > > - Additional profile-level interoperability logic
> > >
> > >
> > But most of these profiles should belong to the userspace, please split
> the
> > related code to nuttx-apps.git, instead nuttx/.
> > especially, the code related shell spread in the whole code base:
> >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > it's definitely wrong to put the shell code inside kernel space.
> >
> >
> > > The Zephyr Bluetooth stack already provides a broad and actively
> > maintained
> > > implementation across many of these areas. Rebuilding equivalent
> > > functionality directly on top of the current NuttX Bluetooth stack
> would
> > > require a very large multi-year effort, including not only protocol
> > > implementation but also interoperability testing with real phones,
> > > headsets, speakers, cars, and other commercial devices.
> > >
> > > Therefore, our goal is not to discard NuttX's existing work lightly,
> but
> > to
> > > provide a practical path to make NuttX capable of supporting a much
> wider
> > > Bluetooth feature set in a reasonable time frame.
> > > ------------------------------
> > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > >
> > > Another important discussion point is whether the new Bluetooth stack
> > > should live in nuttx-apps, similar to how NimBLE is currently
> integrated.
> > >
> > > Our concern is that a host stack is not just an application-level
> > > component. It interacts closely with:
> > >
> > > - HCI transport
> > > - L2CAP channels
> > > - Socket or device interfaces
> > > - Memory pools
> > > - Timers and work queues
> > > - Security and pairing state
> > > - Profile registration
> > > - Controller event dispatch
> > > - Future kernel/user boundary mechanisms
> > >
> > > Putting the core host stack in nuttx-apps would either require exposing
> > > many internal kernel interfaces or would force the application-side
> stack
> > > to depend on non-public NuttX internals.
> > >
> > > We already have a similar problem with the current NimBLE integration.
> > The
> > > NimBLE port in nuttx-apps directly depends on many NuttX
> kernel/internal
> > > APIs. As a result, it is difficult to support protected/kernel builds
> > > cleanly, and it is also hard to keep the port synchronized with
> upstream
> > > NimBLE over time.
> > >
> > >
> > These are kernel public API, the only problem is that they are called by
> > userspace.
> >
> >
> > > For this reason, we believe the Bluetooth host core belongs in the
> NuttX
> > > tree. User-facing profiles, tools, shell commands, or demo applications
> > can
> > > still live outside the core as appropriate, but the transport-facing
> host
> > > stack should have a well-defined place inside NuttX.
> > >
> > > There is also a performance consideration. In flat build mode, the
> > > Bluetooth host stack can run directly on the kernel side without
> > additional
> > > syscall or user/kernel boundary overhead. This is especially important
> > for
> > > IoT chips with relatively low CPU frequency, where Bluetooth data path
> > and
> > > profile handling overhead can have a visible impact on throughput,
> > latency,
> > > and power consumption.
> > >
> > > At the same time, this does not mean that the final architecture must
> > > remain flat-build-only. A compatible evolution path is to keep the
> > > performance-sensitive transport and host core on the kernel side, while
> > > gradually moving suitable Bluetooth profile implementations or
> > > profile-facing helper layers into libc-visible build paths. This allows
> > > protected and kernel builds to use proper public interfaces, while
> still
> > > preserving good performance for flat build and low-end IoT platforms.
> > >
> > > In other words, placing the stack in nuttx gives us a cleaner long-term
> > > architecture:
> > >
> > > - Flat build can get the best performance with minimum overhead.
> > > - Protected/kernel build can be supported later through proper
> public
> > > interfaces.
> > > - Profile code can be migrated into libc-compatible paths where
> > > appropriate.
> > > - Userspace does not need to directly depend on private kernel
> > symbols.
> > > - The design avoids repeating the long-term maintainability issue
> seen
> > > in some existing userspace Bluetooth integrations.
> > >
> > >
> >
> > But Zephyr bluetooth stack is implemented as a monolithic block like
> > NimBLE.
> > Your current porting just include:
> >
> > 1. Switch Zephyr API to NuttX kernel API
> > 2. Format the code base to follow The NuttX coding style
> >
> > No any change related to the kernel/user space separation, so it's better
> > to contain in nuttx-apps.git in the current stage.
> > I would suggest you put the initial code inside nuttx-apps and move the
> > part which belongs to the kernel step by step,
> > so the community can review the change more carefully.
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Oct 16, 2026 at 12:53 PM chao an <ma...@gmail.com> wrote:
> No, I do not agree that the current port is only a Zephyr API replacement
> and
> NuttX coding-style reformatting.
>
>
>
> This code base has already fixed part of the issues that still exist in the
>
> Zephyr community implementation. In addition, we still have pending
> features and
> fixes that have not been submitted yet. Since some of those changes were
> made by
> other developers, I cannot submit their work by myself without proper
> permission
> and attribution.
>
>
> https://github.com/zephyrproject-rtos/zephyr/pull/122348
>
>
> I have already stated in the email why I do not recommend putting the
> initial
> Bluetooth host stack into nuttx-apps. Architecturally, placing it in apps
> would
> cause significant performance degradation compared with the Zephyr design.
> The
> Bluetooth host stack is tightly coupled with kernel primitives, buffer
>
> management, work queues, timing, and HCI/driver paths. Moving it entirely
> to
> apps would change that integration model and make the architecture worse
> from
> the beginning.
>
>
I don't see any performance degradation by moving your whole patch to
nuttx-apps.git.
You can call kernel api directly and the bluetooth stack still can only run
in the flat mode.
And then you can do the planned work by moving the suitable component to
kernel spaces.
>
> Therefore, please read my previous email more carefully. The concern here
> is not
> only the initial review size, but also the long-term architecture and
> runtime
> performance of the Bluetooth stack in NuttX.
>
> BRs,
>
> Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
>
> > On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I would like to summarize the background, technical motivation, and
> > > proposed evolution plan for PR #20686, which introduces a Zephyr-based
> > > Bluetooth host stack under net/bt.
> > >
> > > https://github.com/apache/nuttx/pull/20686
> > >
> > > First of all, I fully understand the concerns raised in the discussion.
> > > Adding a new Bluetooth stack is a significant architectural change, and
> > it
> > > is reasonable for the community to ask whether we should instead
> continue
> > > improving the existing NuttX Bluetooth implementation. I would like to
> > > explain why we believe introducing the new stack incrementally is the
> > more
> > > practical path, while still keeping the long-term NuttX architecture
> > clean
> > > and maintainable.
> > > ------------------------------
> > > 1. Why not only enhance the existing NuttX Bluetooth stack?
> > >
> > > The existing NuttX Bluetooth implementation is mainly focused on BLE
> > > functionality. However, modern Bluetooth support is no longer limited
> to
> > > basic BLE. A complete Bluetooth host stack now commonly includes:
> > >
> > > - BLE GAP/GATT/ATT/SMP
> > > - Classic Bluetooth profiles
> > > - A2DP
> > > - AVRCP
> > > - HFP/HSP
> > > - HID
> > > - LE Mesh
> > > - LE Audio
> > > - Additional profile-level interoperability logic
> > >
> > >
> > But most of these profiles should belong to the userspace, please split
> the
> > related code to nuttx-apps.git, instead nuttx/.
> > especially, the code related shell spread in the whole code base:
> >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
> >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
> >
> >
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
> >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
> >
> >
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> > it's definitely wrong to put the shell code inside kernel space.
> >
> >
> > > The Zephyr Bluetooth stack already provides a broad and actively
> > maintained
> > > implementation across many of these areas. Rebuilding equivalent
> > > functionality directly on top of the current NuttX Bluetooth stack
> would
> > > require a very large multi-year effort, including not only protocol
> > > implementation but also interoperability testing with real phones,
> > > headsets, speakers, cars, and other commercial devices.
> > >
> > > Therefore, our goal is not to discard NuttX's existing work lightly,
> but
> > to
> > > provide a practical path to make NuttX capable of supporting a much
> wider
> > > Bluetooth feature set in a reasonable time frame.
> > > ------------------------------
> > > 2. Why place the stack in nuttx instead of nuttx-apps?
> > >
> > > Another important discussion point is whether the new Bluetooth stack
> > > should live in nuttx-apps, similar to how NimBLE is currently
> integrated.
> > >
> > > Our concern is that a host stack is not just an application-level
> > > component. It interacts closely with:
> > >
> > > - HCI transport
> > > - L2CAP channels
> > > - Socket or device interfaces
> > > - Memory pools
> > > - Timers and work queues
> > > - Security and pairing state
> > > - Profile registration
> > > - Controller event dispatch
> > > - Future kernel/user boundary mechanisms
> > >
> > > Putting the core host stack in nuttx-apps would either require exposing
> > > many internal kernel interfaces or would force the application-side
> stack
> > > to depend on non-public NuttX internals.
> > >
> > > We already have a similar problem with the current NimBLE integration.
> > The
> > > NimBLE port in nuttx-apps directly depends on many NuttX
> kernel/internal
> > > APIs. As a result, it is difficult to support protected/kernel builds
> > > cleanly, and it is also hard to keep the port synchronized with
> upstream
> > > NimBLE over time.
> > >
> > >
> > These are kernel public API, the only problem is that they are called by
> > userspace.
> >
> >
> > > For this reason, we believe the Bluetooth host core belongs in the
> NuttX
> > > tree. User-facing profiles, tools, shell commands, or demo applications
> > can
> > > still live outside the core as appropriate, but the transport-facing
> host
> > > stack should have a well-defined place inside NuttX.
> > >
> > > There is also a performance consideration. In flat build mode, the
> > > Bluetooth host stack can run directly on the kernel side without
> > additional
> > > syscall or user/kernel boundary overhead. This is especially important
> > for
> > > IoT chips with relatively low CPU frequency, where Bluetooth data path
> > and
> > > profile handling overhead can have a visible impact on throughput,
> > latency,
> > > and power consumption.
> > >
> > > At the same time, this does not mean that the final architecture must
> > > remain flat-build-only. A compatible evolution path is to keep the
> > > performance-sensitive transport and host core on the kernel side, while
> > > gradually moving suitable Bluetooth profile implementations or
> > > profile-facing helper layers into libc-visible build paths. This allows
> > > protected and kernel builds to use proper public interfaces, while
> still
> > > preserving good performance for flat build and low-end IoT platforms.
> > >
> > > In other words, placing the stack in nuttx gives us a cleaner long-term
> > > architecture:
> > >
> > > - Flat build can get the best performance with minimum overhead.
> > > - Protected/kernel build can be supported later through proper
> public
> > > interfaces.
> > > - Profile code can be migrated into libc-compatible paths where
> > > appropriate.
> > > - Userspace does not need to directly depend on private kernel
> > symbols.
> > > - The design avoids repeating the long-term maintainability issue
> seen
> > > in some existing userspace Bluetooth integrations.
> > >
> > >
> >
> > But Zephyr bluetooth stack is implemented as a monolithic block like
> > NimBLE.
> > Your current porting just include:
> >
> > 1. Switch Zephyr API to NuttX kernel API
> > 2. Format the code base to follow The NuttX coding style
> >
> > No any change related to the kernel/user space separation, so it's better
> > to contain in nuttx-apps.git in the current stage.
> > I would suggest you put the initial code inside nuttx-apps and move the
> > part which belongs to the kernel step by step,
> > so the community can review the change more carefully.
> >
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by chao an <ma...@gmail.com>.
No, I do not agree that the current port is only a Zephyr API replacement
and
NuttX coding-style reformatting.
This code base has already fixed part of the issues that still exist in the
Zephyr community implementation. In addition, we still have pending
features and
fixes that have not been submitted yet. Since some of those changes were
made by
other developers, I cannot submit their work by myself without proper
permission
and attribution.
https://github.com/zephyrproject-rtos/zephyr/pull/122348
I have already stated in the email why I do not recommend putting the
initial
Bluetooth host stack into nuttx-apps. Architecturally, placing it in apps
would
cause significant performance degradation compared with the Zephyr design.
The
Bluetooth host stack is tightly coupled with kernel primitives, buffer
management, work queues, timing, and HCI/driver paths. Moving it entirely
to
apps would change that integration model and make the architecture worse
from
the beginning.
Therefore, please read my previous email more carefully. The concern here
is not
only the initial review size, but also the long-term architecture and
runtime
performance of the Bluetooth stack in NuttX.
BRs,
Xiang Xiao <xi...@gmail.com> 于2026年10月16日周五 12:44写道：
> On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com> wrote:
>
> > Hi all,
> >
> > I would like to summarize the background, technical motivation, and
> > proposed evolution plan for PR #20686, which introduces a Zephyr-based
> > Bluetooth host stack under net/bt.
> >
> > https://github.com/apache/nuttx/pull/20686
> >
> > First of all, I fully understand the concerns raised in the discussion.
> > Adding a new Bluetooth stack is a significant architectural change, and
> it
> > is reasonable for the community to ask whether we should instead continue
> > improving the existing NuttX Bluetooth implementation. I would like to
> > explain why we believe introducing the new stack incrementally is the
> more
> > practical path, while still keeping the long-term NuttX architecture
> clean
> > and maintainable.
> > ------------------------------
> > 1. Why not only enhance the existing NuttX Bluetooth stack?
> >
> > The existing NuttX Bluetooth implementation is mainly focused on BLE
> > functionality. However, modern Bluetooth support is no longer limited to
> > basic BLE. A complete Bluetooth host stack now commonly includes:
> >
> > - BLE GAP/GATT/ATT/SMP
> > - Classic Bluetooth profiles
> > - A2DP
> > - AVRCP
> > - HFP/HSP
> > - HID
> > - LE Mesh
> > - LE Audio
> > - Additional profile-level interoperability logic
> >
> >
> But most of these profiles should belong to the userspace, please split the
> related code to nuttx-apps.git, instead nuttx/.
> especially, the code related shell spread in the whole code base:
>
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
>
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
>
> https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
>
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
>
> https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
> it's definitely wrong to put the shell code inside kernel space.
>
>
> > The Zephyr Bluetooth stack already provides a broad and actively
> maintained
> > implementation across many of these areas. Rebuilding equivalent
> > functionality directly on top of the current NuttX Bluetooth stack would
> > require a very large multi-year effort, including not only protocol
> > implementation but also interoperability testing with real phones,
> > headsets, speakers, cars, and other commercial devices.
> >
> > Therefore, our goal is not to discard NuttX's existing work lightly, but
> to
> > provide a practical path to make NuttX capable of supporting a much wider
> > Bluetooth feature set in a reasonable time frame.
> > ------------------------------
> > 2. Why place the stack in nuttx instead of nuttx-apps?
> >
> > Another important discussion point is whether the new Bluetooth stack
> > should live in nuttx-apps, similar to how NimBLE is currently integrated.
> >
> > Our concern is that a host stack is not just an application-level
> > component. It interacts closely with:
> >
> > - HCI transport
> > - L2CAP channels
> > - Socket or device interfaces
> > - Memory pools
> > - Timers and work queues
> > - Security and pairing state
> > - Profile registration
> > - Controller event dispatch
> > - Future kernel/user boundary mechanisms
> >
> > Putting the core host stack in nuttx-apps would either require exposing
> > many internal kernel interfaces or would force the application-side stack
> > to depend on non-public NuttX internals.
> >
> > We already have a similar problem with the current NimBLE integration.
> The
> > NimBLE port in nuttx-apps directly depends on many NuttX kernel/internal
> > APIs. As a result, it is difficult to support protected/kernel builds
> > cleanly, and it is also hard to keep the port synchronized with upstream
> > NimBLE over time.
> >
> >
> These are kernel public API, the only problem is that they are called by
> userspace.
>
>
> > For this reason, we believe the Bluetooth host core belongs in the NuttX
> > tree. User-facing profiles, tools, shell commands, or demo applications
> can
> > still live outside the core as appropriate, but the transport-facing host
> > stack should have a well-defined place inside NuttX.
> >
> > There is also a performance consideration. In flat build mode, the
> > Bluetooth host stack can run directly on the kernel side without
> additional
> > syscall or user/kernel boundary overhead. This is especially important
> for
> > IoT chips with relatively low CPU frequency, where Bluetooth data path
> and
> > profile handling overhead can have a visible impact on throughput,
> latency,
> > and power consumption.
> >
> > At the same time, this does not mean that the final architecture must
> > remain flat-build-only. A compatible evolution path is to keep the
> > performance-sensitive transport and host core on the kernel side, while
> > gradually moving suitable Bluetooth profile implementations or
> > profile-facing helper layers into libc-visible build paths. This allows
> > protected and kernel builds to use proper public interfaces, while still
> > preserving good performance for flat build and low-end IoT platforms.
> >
> > In other words, placing the stack in nuttx gives us a cleaner long-term
> > architecture:
> >
> > - Flat build can get the best performance with minimum overhead.
> > - Protected/kernel build can be supported later through proper public
> > interfaces.
> > - Profile code can be migrated into libc-compatible paths where
> > appropriate.
> > - Userspace does not need to directly depend on private kernel
> symbols.
> > - The design avoids repeating the long-term maintainability issue seen
> > in some existing userspace Bluetooth integrations.
> >
> >
>
> But Zephyr bluetooth stack is implemented as a monolithic block like
> NimBLE.
> Your current porting just include:
>
> 1. Switch Zephyr API to NuttX kernel API
> 2. Format the code base to follow The NuttX coding style
>
> No any change related to the kernel/user space separation, so it's better
> to contain in nuttx-apps.git in the current stage.
> I would suggest you put the initial code inside nuttx-apps and move the
> part which belongs to the kernel step by step,
> so the community can review the change more carefully.
>
Re: PR #20686 — Introducing a Zephyr-based Bluetooth host stack under net/bt: background, technical motivation, and proposed evolution plan
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Oct 16, 2026 at 11:25 AM chao an <ma...@gmail.com> wrote:
> Hi all,
>
> I would like to summarize the background, technical motivation, and
> proposed evolution plan for PR #20686, which introduces a Zephyr-based
> Bluetooth host stack under net/bt.
>
> https://github.com/apache/nuttx/pull/20686
>
> First of all, I fully understand the concerns raised in the discussion.
> Adding a new Bluetooth stack is a significant architectural change, and it
> is reasonable for the community to ask whether we should instead continue
> improving the existing NuttX Bluetooth implementation. I would like to
> explain why we believe introducing the new stack incrementally is the more
> practical path, while still keeping the long-term NuttX architecture clean
> and maintainable.
> ------------------------------
> 1. Why not only enhance the existing NuttX Bluetooth stack?
>
> The existing NuttX Bluetooth implementation is mainly focused on BLE
> functionality. However, modern Bluetooth support is no longer limited to
> basic BLE. A complete Bluetooth host stack now commonly includes:
>
> - BLE GAP/GATT/ATT/SMP
> - Classic Bluetooth profiles
> - A2DP
> - AVRCP
> - HFP/HSP
> - HID
> - LE Mesh
> - LE Audio
> - Additional profile-level interoperability logic
>
>
But most of these profiles should belong to the userspace, please split the
related code to nuttx-apps.git, instead nuttx/.
especially, the code related shell spread in the whole code base:
https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/audio/shell
https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/classic/shell
https://github.com/anchao/nuttx/tree/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/host/shell
https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/mesh/shell/
https://github.com/anchao/nuttx/blob/6d6ddbb271cfdeb3e0993b5ebe992b4eab858c6c/net/bt/services/ias/shell
it's definitely wrong to put the shell code inside kernel space.
> The Zephyr Bluetooth stack already provides a broad and actively maintained
> implementation across many of these areas. Rebuilding equivalent
> functionality directly on top of the current NuttX Bluetooth stack would
> require a very large multi-year effort, including not only protocol
> implementation but also interoperability testing with real phones,
> headsets, speakers, cars, and other commercial devices.
>
> Therefore, our goal is not to discard NuttX's existing work lightly, but to
> provide a practical path to make NuttX capable of supporting a much wider
> Bluetooth feature set in a reasonable time frame.
> ------------------------------
> 2. Why place the stack in nuttx instead of nuttx-apps?
>
> Another important discussion point is whether the new Bluetooth stack
> should live in nuttx-apps, similar to how NimBLE is currently integrated.
>
> Our concern is that a host stack is not just an application-level
> component. It interacts closely with:
>
> - HCI transport
> - L2CAP channels
> - Socket or device interfaces
> - Memory pools
> - Timers and work queues
> - Security and pairing state
> - Profile registration
> - Controller event dispatch
> - Future kernel/user boundary mechanisms
>
> Putting the core host stack in nuttx-apps would either require exposing
> many internal kernel interfaces or would force the application-side stack
> to depend on non-public NuttX internals.
>
> We already have a similar problem with the current NimBLE integration. The
> NimBLE port in nuttx-apps directly depends on many NuttX kernel/internal
> APIs. As a result, it is difficult to support protected/kernel builds
> cleanly, and it is also hard to keep the port synchronized with upstream
> NimBLE over time.
>
>
These are kernel public API, the only problem is that they are called by
userspace.
> For this reason, we believe the Bluetooth host core belongs in the NuttX
> tree. User-facing profiles, tools, shell commands, or demo applications can
> still live outside the core as appropriate, but the transport-facing host
> stack should have a well-defined place inside NuttX.
>
> There is also a performance consideration. In flat build mode, the
> Bluetooth host stack can run directly on the kernel side without additional
> syscall or user/kernel boundary overhead. This is especially important for
> IoT chips with relatively low CPU frequency, where Bluetooth data path and
> profile handling overhead can have a visible impact on throughput, latency,
> and power consumption.
>
> At the same time, this does not mean that the final architecture must
> remain flat-build-only. A compatible evolution path is to keep the
> performance-sensitive transport and host core on the kernel side, while
> gradually moving suitable Bluetooth profile implementations or
> profile-facing helper layers into libc-visible build paths. This allows
> protected and kernel builds to use proper public interfaces, while still
> preserving good performance for flat build and low-end IoT platforms.
>
> In other words, placing the stack in nuttx gives us a cleaner long-term
> architecture:
>
> - Flat build can get the best performance with minimum overhead.
> - Protected/kernel build can be supported later through proper public
> interfaces.
> - Profile code can be migrated into libc-compatible paths where
> appropriate.
> - Userspace does not need to directly depend on private kernel symbols.
> - The design avoids repeating the long-term maintainability issue seen
> in some existing userspace Bluetooth integrations.
>
>
But Zephyr bluetooth stack is implemented as a monolithic block like NimBLE.
Your current porting just include:
1. Switch Zephyr API to NuttX kernel API
2. Format the code base to follow The NuttX coding style
No any change related to the kernel/user space separation, so it's better
to contain in nuttx-apps.git in the current stage.
I would suggest you put the initial code inside nuttx-apps and move the
part which belongs to the kernel step by step,
so the community can review the change more carefully.