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 - 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
signature.asc
Description: This is a digitally signed message part
