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? > > > > >
