:stuff that Sam removed from FreeBSD's net80211. I'd like to see this
:portable to multiple operating systems rather than directly fondling
:some FreeBSD stuff.
:
:We can talk more about this at bsdcan if you/I are going.
:
:FWIW - 802.11ac is > 1GBit/sec PHY rate wireless and people are
:already thinking of embedded devices with multiple 11ac NICs in them.
:Scary stuff. :)
:
:Adrian
I don't know if I'll be at BSDCAN yet or not.
The biggest problem the 802.11 infrastructure has is that its complexity
winds up crashing the system, and I don't see that complexity ever
being reduced.
One thing that struck me while looking at the code is that all of the
complexity of the 802.11 device infrastructure that implements the
'wlan' pseudo-interface could be moved to userland... everything except
the actual transmission and reception of a packet, which would use
existing direct paths inside the kernel. It might also be possible to
do away with the wlan pseudo-interface as well, or perhaps operate it
similarly to TAP/TUN (where the userland infrastructure code would
sit between the WLAN pseudo-interface and a physical interface like
'ath'). With a bypass for bulk packet rx and tx, of course.
The API at the physical device (aka 'ath') layer could then be
implemented via ioctls instead of kernel<->kernel API function calls,
leading to more straight-forward locking.
This would also greatly reduce the memory footprint of the implementation
since the system can release the text userland pages, most of which
won't be accessed once the wifi connection is setup (except for the
beacon code, of course).
It would be a lot of work but might also be the only way to make the
infrastructure reliable. It would certainly make it a lot easier to
maintain the infrastructure. In anycase, that could well be a pipe
dream. I can only speak from the armchair when it comes to wifi,
100% of my focus this year is on HAMMER2.
-Matt
Matthew Dillon
<dil...@backplane.com>
