|To:||Denis Vlasenko <vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>|
|Subject:||Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack|
|From:||Sam Leffler <sam@xxxxxxxxx>|
|Date:||Wed, 8 Sep 2004 20:31:18 -0700|
|Cc:||netdev@xxxxxxxxxxx, Vladimir Kondratiev <vkondra@xxxxxxx>, prism54-devel@xxxxxxxxxxx, greg chesson <greg@xxxxxxxxxxx>, acx100-devel@xxxxxxxxxxxxxxxxxxxxx, jgarzik@xxxxxxxxx, hadi@xxxxxxxxxx, jkmaline@xxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>|
|References:||<email@example.com> <413F2D33.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>|
On Sep 8, 2004, at 2:19 PM, Denis Vlasenko wrote:
On Wednesday 08 September 2004 22:51, Vladimir Kondratiev wrote:Greg,
The net80211 code has generic 802.11 management handling based on wireless extensions. Drivers that sit beneath it and have the necessary capabilities automatically are usable, for example, with wpa_supplicant (and soon hostapd). At the moment there is one driver for Linux--the ath driver for Atheros h/w.
Rate control is another can-o-worms. The model we've taken is that it is driver-specific.
I'd be very surprised to see "softmac" h/w come along that requires the host to generate ACK frames explicitly; the timing is very tight and it would suck a lot of cycles from the host.
Experience with net80211 indicates you're fine if you have a good 802.11 protocol implementation to fall back on. Then devices that have functionality in h/w just supplant the s/w support. The net80211 code defines a set of device capabilities that indicate, for example, when a device supports various h/w crypto algorithms. Class-like method override mechanisms are used to handle other issues.
This stuff is constantly evolving as more devices are hooked up but in general it's worked out pretty well. I've tried to avoid a spaghetti web of function pointers using callbacks only where it seems most drivers will make use of them. For other cases it often is easier to grab control early on so it's easier to optimize+share code. A concrete example of this is the processing of 802.11 management frames where the original code (that David saw) had an array of function pointers to little routines that handled each frame type--it turned out drivers didn't override these pointers so I removed them and drivers that want to override the default processing override the "recv management" method to intercept specific frames.
To evaluate a design and implementation show support for a few devices at each end of the spectrum. The Atheros h/w is probably a good example of softmac h/w. ADMTek 8211 is also in this category. I'd consider Prism devices toward the other end. You also need to be sure you handle single- and dual-band operation as each have different requirements. Also 11g support takes work to get right so be sure you have a softmac 11g card in the pile. Past that you get into the security protocols, WME/WMM, etc.
Sound like a lot of work? It is.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: generic 802.11 stack, Sam Leffler|
|Next by Date:||[IP6IP6] Handle ECN correctly, Herbert Xu|
|Previous by Thread:||Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack, Denis Vlasenko|
|Next by Thread:||Re: r8169 1.6LK lockup, Pascal de Bruijn|
|Indexes:||[Date] [Thread] [Top] [All Lists]|