pondering WiFi forwards
Bjoern A. Zeeb
bz at FreeBSD.org
Mon Apr 27 13:58:19 UTC 2020
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
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
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)”  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
$ find . -type f -name "*.[ch]" | xargs wc -l | tail -1
The changes (including build framework) since the FreeBSD worktree was
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
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  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.
More information about the freebsd-wireless