I have some reasonably drastic net80211 stack changes planned over the
next few months which require some driver work to make happen. The
specific big change is to call net80211 for each mbuf transmit
completion so it can kick-start the next transmit from a software
staging queue. Since this has to happen outside of any driver lock
context, it can get a bit hairy.
I'm going to do it for the following NICs as I have enough hardware to
* ath (obviously)
* ipw, if I can find the 2200 series NIC
* iwi - same deal, if I can find the hardware
If I can find a bwi and bwn NIC that works enough for basic traffic
testing, I'll also do those NICs.
There's a reasonably active group of people who (especially using USB
wifi NICs) that I plan on enlisting to help me test those drivers.
However, I can't test wi - the lucent/orinoco driver. Some changes
were made a few years ago that changed the encapsulation frame format
from 802.3 to 802.11 and this only seems to work on a very narrow,
specific set of NICs and firmware. I have a _big_ collection of wi
hardware and _I_ can't get it to work. I started hacking on it in 2011
and quickly realised that although I could likely back out the 802.3
-> 802.11 encapsulation changes so things work with a wider variety of
NICs, I don't really want to.
So, I'm going to disconnect wi(4) from the build in a week's time and
shortly after I'm going to nuke it from the repository. As far as I'm
aware no-one has actively used it in a number of years.
Now - if someone wants to step up and claim ownership of the driver -
then fix it to go _back_ to the 802.3 frame format and then make it
work again, I'll be very happy.
Sorry. I'd love to claim we still support wi(4) but the truth is that
it's been broken since before I became wireless maintainer and it
doesn't look like it's ever going to get better.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"