acassis commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6198703630
> > As AI’s code generation capability improves, ensuring code quality becomes ever more important. Before the code finish: > > > > 1. keep only the transport/driver layer in kernel space > > 2. change to the socket model > > 3. replace the current bluetooth stack without losing function > > > > I reject to merge this pr. Anyway, you can send email to dev@ and ask other people opinion. > > My recommendation is to keep the protocol stack implementation in the kernel, and use libc to provide the userspace isolation layer for protected/kernel build modes. This way: > > 1. Flat build: The stack runs directly in kernel space with zero overhead — performance comparable to Zephyr. > > 2. Protected/kernel build: The profile/application layer sits in userspace (libc), communicating with the kernel-side transport/driver layer through the socket/VFS interface. > > > This approach gives us the best of both worlds — performance when we need it (flat build), and isolation when we need it (protected/kernel build) — without the drastic rewrite of moving everything to userspace. > > I'd suggest everyone take another look at NuttX's current Bluetooth capabilities. The reality is that many companies are choosing not to adopt NuttX precisely because of the lack of a mature Bluetooth stack. A fully functional Bluetooth host stack is no longer optional — it's a baseline requirement for most IoT products today (BLE, LE Audio, mesh, etc.). > > Adding a proper Bluetooth stack to the kernel is a positive step for promoting NuttX adoption. It unlocks a whole category of use cases that are currently simply not possible, and makes NuttX a viable option for a much broader range of devices. This is good for the entire ecosystem. @jerpelea @acassis @xiaoxiang781216 Hi @anchao I think we need to evolve the NuttX BLE and although the initial BLE stack used on NuttX is the same used on Zephyr that came from Intel, I don't know if we should use the code from Zephyr. Or is it a rewrite from scratch? I think for the size of this PR and the importance of this suggest it should be better if you send first an email to the mailing list explaining your proposal/approach. I think if we use code from Zephyr, the same CVEs which affect them will affect us. And it will prevent the diversity protection (when a company uses multiple RTOSs to avoid an single hacking put down all theirs devices). -- 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]
