anchao commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6195369986
> But this portging should belong userspace, like nimble: https://github.com/apache/nuttx-apps/tree/master/wireless/bluetooth/nimble since it doesn't follow other network stack design which exposes the network functionality through socket interface. BTW, since Zephyr is under the active development, it's better to integrate it through download. At this stage, the entire Bluetooth stack currently only supports flat build. Protected build and kernel build support are planned for Phase 2. Our thinking for Phase 1 is to get the full stack running with complete feature support first. I've also added flat build as a dependency under the CONFIG_BT configuration option. Once this is in place, we'll move the upper-layer profile code entirely into the libc implementation. ## Why flat build first? There are several benefits to this approach: 1. Performance: The current stack can directly call kernel APIs. Compared to userspace APIs, this yields significantly better performance. 2. Bypassing VFS overhead: Under flat build, the HOST side of the stack can bypass the VFS layer entirely. Currently, the VFS layer requires two memory copies during data transfer between the controller and the HOST. For IoT devices — especially those 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. 3. Direct callback path: Ideally, Bluetooth callbacks should fire directly from interrupt context or workqueue callbacks (similar to Zephyr's design), without going through unnecessary abstraction layers. ## Migration Plan The overall migration is broken down into several phases: ### Phase 1 (current) Submit the full-featured Bluetooth stack to the mainline so everyone can collaborate on stabilizing it together. ### Phase 2 Provide both userspace and kernel space support: • Bluetooth profile code will move to libc. • Interaction with the kernel will go through the socket/VFS layer. • This will only take effect under protected build and kernel build modes. • Under flat build, we'll directly map the transport layer (the VFS layer) into direct function calls for maximum performance. ### Phase 3 Once the new stack fully supports NuttX's Bluetooth capabilities: 1. Remove compatibility with the old Bluetooth stack. 2. Make this the standard Bluetooth implementation for NuttX. ## Why not do everything in one commit? A Bluetooth protocol stack is an extremely complex piece of work. It involves different profiles, different L2CAP data link layers (e.g., LE Audio and SCO), each of which may require different implementation approaches within the kernel. Supporting both kernel space and userspace in a single commit is, frankly, not realistic. We need to proceed step by step and gradually refine the architecture into what we envision. My initial implementation is focused on getting the full-featured stack running on NuttX with minimal resource consumption. We'll continue to invest in stabilizing and improving the framework and architecture over subsequent iterations. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
