How do the same drivers work in Linux? Can't "we" "just" "copy" the code from there? Or does the GPL licensing absolutely prevents from analyzing Linux code and using their implementation details?
Two years ago FreeBSD started implementing AC stack [1]. Maybe there could be a collaborative project among the BSDs to get wifi working on the same (or better) level as in Linux? FreeBSD Foundation announced a month ago they are starting to sponsor work on full AC support [2]. Why not to seize the opportunity and unify the wifi stacks so that the drivers are more or less same code between the 2 BSDs? Then any improvement to the stack and any driver would be useful for both projects. Otherwise it looks like it's too much work to be done by one-two devs on occasional basis. The FreeBSD AC todo list [3] (which is still incomplete) looks overwhelming. Anyway, thanks a lot for what is already done! [1] https://adrianchadd.blogspot.com/2017/04/bringing-up-80211ac-on-freebsd.html [2] https://www.phoronix.com/scan.php?page=news_item&px=802.11ac-FreeBSD-Sponsor [3] https://wiki.freebsd.org/WiFi/80211ac On 14/4/20 08:01, Stefan Sperling wrote: > On Tue, Apr 14, 2020 at 11:37:24AM +0100, Kevin Chadwick wrote: >> On 2020-04-14 09:21, Stefan Sperling wrote: >>> Regarding other chipsets, if you want the fastest possible AP on OpenBSD >>> your best option right now is to get a bwfm(4) device, which offloads almost >>> all of its 802.11 operation into a firmware blob running in the embedded >>> system on the device. >> >> Interesting. >> >> BWFM(4) >> CAVEATS >> The firmware is outdated and contains known vulnerabilities. >> >> Any more information on the seriousness of these vulnerabilities? >> >> I can probably look it up in CVS actually but figured it *may* be prudent of >> me >> to highlight that caveat on the list explicitly, in any case. > > I honestly don't know and don't really care. Even if we knew what publicly > known or unknown bugs linger in there, we couldn't do anything about it. > All we can really do is upgrade the firmware and hope for the best. > > The same is true for the Intel wifi chips. > > What's nice about athn(4) is that the full software stack from driver to > hardware is open source, including firmware for USB devices. So it's > possible to fix issues, though it can be quite hard to fix known bugs. > No firmware abstraction means the driver needs to deal with a lot of > complexity all by itself, i.e. problems that engineers at vendors with > proper testing equipment and low-level expertise tend to deal with. >
