On Thu, 2006-10-26 at 00:00 +0200, Johannes Berg wrote: > On Wed, 2006-10-25 at 13:43 -0400, Luis R. Rodriguez wrote: > > > I guess my hope was that d80211 would just be more than a softmac > > implementation. When I hear wireless stack I don't think "softmac > > implementation", I think a robust set of headers and device > > definitions which all wireless devices can share. > > Not just that, a bunch of library functions for example for crypto would > be nice too. That's part of why I've been proposing that the tkip stuff > be library functions that the drivers can call if required, instead of > the bitfields. > > Currently, there's lot of top-down stuff in d80211, it does things which > depend on flags and then instructs the driver to do something. This is > good for a bunch of things, but in some cases where devices vary wildly > it may be better to go for library functions instead. IMHO the TKIP key > computation is such a case, it's trivial for a driver to call phase1 and > phase2 when required. > > > Also I thought we'd ditch WE as it seems we keep fixing it with gum > > (as seen by Linville's latest ABI compatibility fix). > > Well, that was sort of necessary. > > > If that wasn't > > the case then I'm suggesting it -- can we consider ditching WE? > > Well, no. We can make it a second-class citizen like I did with the > cfg80211 work where I made it just one userspace interface for cfg80211 > which admittedly sometimes strange behaviour, but it's still there and > current operations should still work with it (and I'd consider not > working a bug except if userspace never calls 'commit' and expects > things to work) > > > I'd say lets just go for a > > userspace MLME as its already written but I seriously think we need to > > ditch replace WE first. > > It seems no one has a plan on what to do though. > > - Jiri's trying to fix the SMP issues. That's great. > - Jiri also would like to expand ieee80211_conf.c, the stuff I > started for cfg80211 > - I'd like to see a header cleanup, it's necessary. Part of the problem > here is all the sub-ioctl WE foo. Clean that up by moving them into > cfg80211 as required, there's basically one user, wpa_supplicant (and > maybe hostapd), screw the others if there are any
While wpa_supplicant is certainly the main client for stuff directly related to setting up a connection, there are quite a few other users of general WE calls to pull information out of the card, or to receive scan events. So if you want maximum compatibility for a limited amount of work, you can probably consider wpa_supplicant the only client of (s = set, g = get) 1) [s|g] ENCODEEXT 2) [s|g] AUTH 3) [s|g] MLME 4) [s] RATE 5) [s] FREQ 6) [s] SENS 7) [s] AP 8) [s|g] RTS 9) [s|g] FRAG 10)[s|g] GENIE 11)[s|g] PMKSA Notable exceptions: 1) [s|g] ENCODE 2) [s|g] MODE (other stuff turns on promiscuous mode) 3) [s|g] SCAN (other stuff needs to do this too) 4) [s|g] POWER (power management does this, not wpa_supplicant) Of course lots of stuff needs to get RATE, ESSID, AP, FREQ, etc. Dan > - fix people's minds to not expect a perfect solution immediately but > accept something that can be expanded on later. I think we need to > accept some breakage in our development trees to get anywhere at all. > > Actually, the last point should be first. > > Enough rant from me for today, > johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
