Re: Request for architectural review: experimental net80211/LinuxKPI HE station support
Date: Sat, 07 Nov 2026 01:28:00 UTC
[ + @Adrian for viz ] This discussion captures some of the essential debate I heard in various small groups at the FreeBSD Vendor Summit last night: (A) If you don’t have the skill and the experience to contribute a significant new driver but your LLM can, should you? (A1) What if you submit a small patch to an existing driver using an LLM? (A2) What if the driver you’re contributing [to] is completely broken? What’s the down-side of going from “broken” to “working” even if an LLM is involved? (B) If you are massively experienced in driver creation / modification and you use an LLM to generate essentially the same results as A[x], that’s fine, right? RIGHT? Speaking just for myself, I’m trying to avoid (A) while doing (A1) with reviewers who can and are scrutinizing the edits carefully because, as I cut releases in the Daemonarchy AI sandbox, I find stuff and I report it, like any good OSS citizen, and “upstream" has its own process that it’s also in the process of trying to figure out in more detail. I would say to both Denis and Bjoern that perhaps this is an appropriate steam release valve provided by derived projects like Daemonarchy. You want to send projects like mine your PRs or GitHub issues? Go for it, since the answer to both (A) and (B) is “YES, This is a grand experiment with zero-stakes!” Once new HW support enters such a derived project, with releases coming out as often as necessary, the support can be further reworked into “upstream shape” with at least some confidence that the HW does, in fact, actually boot and send packets, put pixels on the screen, make noises from the speakers, whatever. By contrast, when we merged the PC-98 changes into the tree most of us didn’t even know if they worked or not because we did not live in Japan and we did not own NEC PC-98 computers, but we took it on faith that it was worthwhile (after some debate) because those folks seemed to know what they were doing. Maybe that’s where we’re going next, but with a lot of LLM + human reviewers + Real Hardware providing the appropriate change gates. I can only speculate, but I’d be happy to adopt Denis’ patches and see what they do in-situ! - Jordan > On Nov 6, 2026, at 4:47 PM, Denis Lemire <denis@lemire.name> wrote: > >> If I were to ask you a technical question about something in there, could you answer (without LLM)? > > As it sits today, without an LLM, there's a great chance the answer would be no - I hope to get to that level someday. :) > > There's a good, or at least non-zero, chance I could find the answer and maybe even understand it, with LLM assistance. > > Enjoying the opportunity to learn while exploring the problem space on a small scale... Seeking to share successes where I find them. > >> I personally am bound to a at best "read-only LLM" policy so I couldn't currently even if I wanted to. > > Thanks for reading and taking the time to reply, regardless of where the bread ultimately goes. > >> If users want to integrate the work into local trees, they are free to, but they will likely also not see (much/any) support? >> Or would you be able to help them debug problems and will you maintain this code? > > Although this was all LLM driven, I'm using the target machine in a real env and running real workloads on it... It was fascinating to watch the LLM work through the problem space... Real dtrace info gathered...crash dumps and real results in the end, "on my machine..." > > This particular laptop went from struggling to get kilobits per second on my WiFi networking, now pretty decently achieves a couple hundred Mbps... > > There were a couple real bugs along the way that I raised smaller PRs for: > https://github.com/freebsd/freebsd-src/pull/2532 > https://github.com/freebsd/freebsd-src/pull/2531 > > When I saw success with those findings I got curious if the LLM could get this hardware to talk 802.11ac/ax on my network. It did! > > If anyone does happen to try these patches and has success on their own similar hardware or otherwise, I'm happy to collaborate, compare notes, methodology etc... > > Maybe over time the implementation can prove itself and it could be considered merge worthy... if not, maybe it gets someone on-line who struggled prior, even if unofficially. > > -- Denis > > On Fri, Nov 6, 2026 at 5:03 PM Bjoern A. Zeeb <bz@freebsd.org <mailto:bz@freebsd.org>> wrote: >> On Thu, 5 Nov 2026, Denis Lemire wrote: >> >> Hi, >> >> this is my personal take on this. >> >> > I've been developing and testing experimental 802.11ax (HE) station support >> > for FreeBSD, using an HP laptop with a Realtek RTL8852BT and a UniFi U6 >> > Mesh. I'd appreciate architectural review and guidance on the appropriate >> > integration route. >> > >> > The series connects native HE parsing, encoding and owned association state >> > to LinuxKPI peer/BSS capability handoffs, rate calculation and receive >> > metadata. HE defaults off. Testing also exposed separate key/queue ordering >> > and aggregation-stop lock issues, addressed in distinct commits. >> > >> > Source, comprising 21 signed commits based on CURRENT main 12f90bbd3029: >> > https://github.com/denislemire/freebsd-src/tree/codex/80211ax-sta-review >> > >> > Reviewer guide, standalone helper tests and sanitized evidence: >> > https://denis.lemire.name/download/enabling-he-wifi-in-freebsd.pdf >> >> If I were to ask you a technical question about something in there, could you answer (without LLM)? >> >> >> > Fresh CURRENT GENERIC builds with WITNESS and INVARIANTS pass bounded >> > controls with HE disabled and with HE using software or hardware >> > encryption. A separately identified STABLE port also passes IPv4/IPv6 >> > traffic, integrity checks, observed pairwise key renewals and automatic HE >> > startup across a normal reboot. >> > >> > Hardware validation is limited to this adapter/AP combination at 40 MHz. >> > Software encryption remains slower; suspend/resume, broader >> > interoperability and several lifecycle cases need further work. The guide >> > distinguishes hardware observations from modeled helper coverage. >> > >> > Code, tests and prose were developed with AI assistance; I remain >> > responsible for their provenance and claims. >> > >> > I'd appreciate your assessment of whether this is a useful starting point >> > for FreeBSD, what needs to change, and how best to get it reviewed. I'm >> > learning kernel development through this work and would welcome guidance on >> > bringing it up to the project's standards. >> >> I would assume that at this point no (wireless) committer is going to spend any serious time on looking at this to get it integrated. >> Whether this may change in the future will probably depend on other policies of the project. >> >> I personally am bound to a at best "read-only LLM" policy so I couldn't currently even if I wanted to. >> >> If users want to integrate the work into local trees, they are free to, but they will likely also not see (much/any) support? >> Or would you be able to help them debug problems and will you maintain this code? >> >> /bz >> >> -- >> For there shall arise false Christs, and false prophets, and shall shew >> great signs and wonders; insomuch that, if it were possible, they shall >> deceive the very elect. Behold, I have told you before. [Mat. 24:24-25]