anchao commented on code in PR #20686: URL: https://github.com/apache/nuttx/pull/20686#discussion_r4310128364
########## boards/sim/sim/sim/configs/bt/defconfig: ########## @@ -0,0 +1,158 @@ +############################################################################ +# boards/sim/sim/sim/configs/bt/defconfig +# +# Copyright (c) ByteDance Ltd. and/or its affiliates. Review Comment: Let me restate my proposal more clearly: the intention is not to keep all Bluetooth profiles in kernel space. The plan is to keep only the lower Bluetooth transport/protocol layers that need to interact closely with the network/device side in the kernel, especially L2CAP. Higher-level profiles and application-facing logic should be moved out of the kernel and maintained in libs/libbt. So the long-term layering would be: - kernel: controller/HCI integration, core host transport, L2CAP, and other lower-layer pieces that need kernel-side integration; - libs/libbt: higher-level Bluetooth profiles and reusable host-stack logic; - apps: shell commands, tools, demos, and other user-facing code. This still follows the OSI layering principle. I am not proposing that profiles such as audio, GATT services, mesh models, or other application-level logic should permanently live in the kernel. For the current first-stage PR, the main goal is to make the stack build and run in FLAT mode first. In FLAT mode the separation is naturally less strict, and keeping the profile code close to the stack can provide better performance and lower overhead. This is also important if we want NuttX Bluetooth to be competitive with mainstream embedded OS implementations such as Zephyr. However, I agree that this should not become the final layout for Protected and Kernel builds. For the next stage, I plan to move the higher-level profiles into libs/libbt and keep only the necessary lower-layer kernel components in net/bt. The shell code has already been removed from this PR and will be moved to apps, so the current stack no longer contains userspace shell code. In short, I agree with the concern about not putting all OSI layers into the kernel. My proposal is to keep L2CAP and the required lower layers in the kernel, while moving higher-level profiles to libs/libbt as part of the next-stage Protected/Kernel mode support. -- 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]
