but if you look into the details, the separation is false since the call between libs/zblue and net/bluetooth does not go through the POSIX socket interface. It's a huge setback compared with the current kernel bluetooth stack. If you still think it's better to start from the kernel. The right approach is replaced the current bluetooth stack with the new Zephyr L2/L3 like Greg done before since:
1. the code base is much smaller than #20686 2. the code can be tested with apps tool and example directly On Thu, Oct 29, 2026 at 9:36 PM chao an <[email protected]> wrote: > You make a fair point about Greg's patch — it was L2 only, no profiles. The > scale is different. > > > > > > > On the migration direction: my view is that L2CAP belongs in the kernel, > the lower-level profiles stay in nuttx/libs, and higher-level Bluetooth > services and test programs move to apps. This is the UNIX-like layering > I've been advocating from the start — it's not "everything in kernel > forever," it's a proper separation of concerns. > > BRs, > > Xiang Xiao <[email protected]> 于2026年10月29日周四 21:30写道： > > > But Greg's patch just contains L2 code, no profile code at all. > > Both proposal will achieve the same global in the end, let me highlight > > again the difference again: > > > > The difference from PR #20686 is the direction of migration: > > > > - PR #20686 puts the whole host into the kernel first and plans to move > > parts back to userspace later. > > - We start with a complete, product-proven host in userspace, and move > > the > > L2/L3 layers into the kernel step by step, only where the community > > agrees. > > > > so, let's ignore the details, but focus on which direction the community > > prefers. > > > > Thanks > > Xiang > > > > On Thu, Oct 29, 2026 at 9:01 PM chao an <[email protected]> wrote: > > > > > Tomek, > > > > > > I think you should take a look at the history of NuttX's existing > native > > > Bluetooth stack. It was also ported from Zephyr by Greg Nutt — here's > the > > > original commit: > > > > > > > > > > > > https://github.com/apache/nuttx/commit/accef0ca9e96ced73ebe3e141975993edb52d42e > > > > > > That stack was brought in-tree, adapted to NuttX's APIs and threading > > > model, and evolved through many subsequent commits to fill in the > missing > > > pieces. This is exactly the same pattern I'm following with libs/zblue. > > So > > > I have to ask — do you also take issue with that earlier fork? Or were > > the > > > CVE concerns somehow not applicable back then? > > > > > > > > >
