Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211

[Dan Williams <dcbw@redhat.com>]

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