| |||||||||||||
nl80211 is not tied to d80211nl80211 is not tied to d80211Posted Oct 5, 2006 9:59 UTC (Thu) by johill (subscriber, #25196)Parent article: The final wireless extension?
That's actually a common misconception, but is just not true. Any card can register a cfg80211 operations structure and be configured with nl80211 (and WE through it too soon!). In fact, I wrote cfg80211/nl80211 very much with that in mind.
(Log in to post comments)
Incremental, or all-at-once migration? Posted Oct 5, 2006 13:57 UTC (Thu) by pizza (subscriber, #46) [Link] So does every 802.11 driver now have to implement nl80211 independently, and in addition to WE?
And will this result in the same "every implementation is slightly different and buggy" mess that WE had for so long?
Incremental, or all-at-once migration? Posted Oct 6, 2006 8:52 UTC (Fri) by johill (subscriber, #25196) [Link] Well, first of all, drivers are expected to implement cfg80211 which is (I hope!) a clearly defined interface using structs and callbacks instead of the SIOCxIWxxx madness.
Secondly, I just posted a patch yesterday (though netdev rejected it) to make it possible to use WE as a userspace interface to cfg80211, and make it possible to convert drivers one by one (even one configuration call at a time!).
Yes, it is now necessary to convert each driver, however, the semantics are hopefully much clearer defined. It was never clear, for example, what SIOCGIWAP was supposed to return because it was overloaded for two purposes, so drivers did it differently. cfg80211 separates it out into two calls, and tries to do a best-effort for WE-userspace.
|
|||||||||||||