pondering WiFi forwards

[Bjoern A. Zeeb]

Hi,

there is a longer-term vision that’s been floating around for more 
than a year now.  I was contemplating it last year around BSDCan times 
when my private life came in the way.  Times now are not exactly easy 
for most of us either at the moment.  I want to float it around for 
discussion anyway.

First I’d love to say thank you, everyone who has worked on wifi in 
the last two decades for FreeBSD.  You deserve massive thanks and cheers 
as you made it work, kept it working, kept users happy!

The fact is that looking back, for a long time now, (Free)BSD has been 
running behind the WiFi game.  Like every BSD we don’t have enough 
hands.  We’ve been porting drivers from one another and most of them 
from a Linux upstream or otherwise, e.g., via documentation.
The current state is:  we are lacking ac, ax, ay, ad, .. some mesh, some 
“IoT standards”, .., we are constantly lacking support for newer 
chipsets or even entire drivers.

A lot of Linux drivers are currently Dual-Licensed or ISC licensed so we 
could just “take” them.
We may not always like their coding style, they have different 
infrastructure, locking models, ..  that’s all sortable.
We saw that with drivers for wired networking, where vendors have a 
common “library” part and an os specific part to the extend 
possible.
We see that it is possible with OpenZFS now where people are targeting 5 
different OSes (to my knowledge).
Neither happened over night.
Graphics is in a similar position I’d guess though way ahead of WiFi.

One thing that I personally see is that for as long as we look at 
upstream drivers and re-write them to our style and needs we’ll keep 
playing the 2nd class citizen game as we’ll have close to no chance to 
ever engage with upstream and only do the catch-up.
We get snapshots at the time we port a driver with the features we have 
at that moment; moving forward afterwards means tracking upstream and 
keep porting things.  If that work stalls, it is even harder for someone 
else to pick it up due to all the rewriting.
It’s even harder if the path was upstream -> one BSD -> two BSD -> 
this BSD as we do have for some drivers.  This often (only and 
thankfully) worked as one of you was responsible for all three BSDs :-)

If you’ve seen the EuroBSDCon talk “Wireless Fidelity with 
bwfm(4)” [3] or looked at other WiFi driver ports they can take quite 
a while (especially if done in spare time).

I recently looked at the ath10k code noticed this:
The current total lines of upstream code measured like this (rough 
estimate):
$ find . -type f -name "*.[ch]" | xargs wc -l | tail -1
    61094 total
The changes (including build framework) since the FreeBSD worktree was 
initially branched:
  62 files changed, 37953 insertions(+), 6315 deletions(-)
That is half the upstream driver having changed basically.
If you cannot just create the diff from git and fast-forward most parts 
(re-)applying these changes might be a massive effort but even if you 
can do this along, maintenance stays a big task.

The bottom line is: we need to find a way to make it easier to port 
drivers over, on the hw attach side, on the 80211 side, on the data path 
side.
We need to catch up to support the newer standards.
And then we should try to engage with upstream as well; but we do need 
to do our homework first.

And we need this not only for the “in-tree” drivers, we need this 
for all drivers.  If it is easy to port a driver, a non-friendly 
licensed driver can always live in ports, as it’s sometimes better to 
support something than nothing for users.  And if porting is easier that 
means more people can help as the bar to entrance is lower.  And that 
gets us out of the “hands” problem.

FreeBSD has downstream consumers, Haiku, RTEMS (to my knowledge), NetBSD 
is synching from us as well [4] and I hope we can extend this 
“synching” more into collaborations and stay on the same page 
all-together also with the other BSDs in the future.

If it is, this is not going to happen in the next weeks or months.  How, 
I don’t know exactly yet.  Some of this would probably be a largely 
iterative process.  Some of this will require more work now and delay a 
few things a bit, some of the things we’ve been missing for too long 
already.   The hope is that in the long-term it’ll be more rewarding 
for everyone.  As the Phoronix article says “There is a lot of work 
left and years overdue.”  We’d all love to just snip our fingers now 
and have this all solved in an instant.  If you can please do ;-)


Also, if you’d love to do something WiFi and not port and get working 
an entire driver, yet equally important, there’s PRs open for current 
drivers, the maintenance mentioned earlier to be done on quite a few, 
which equally would want someone looking at them.


Any comments, questions (as much as I can answer at this point), .. 
would be appreciated.


/bz


[3] https://www.youtube.com/watch?v=8N0IL8APCHg&t=1m40s
[4] https://blog.netbsd.org/tnf/entry/wifi_renewal_restarted