On Sat, 2007-06-16 at 20:51 +0200, Johannes Berg wrote:
> On Sat, 2007-06-16 at 11:29 -0700, Michael Wu wrote:
>
> > I think that decision was made without much consideration to the
> > implementation details.
>
> I don't think the implementation details are much of a problem. It's
> just a bit of message bouncing which is trivial. Except of course when
> you consider wext, but hey, no need to consider that for this discussion
> since you're proposing ditching wext completely. Not that I don't want
> to ditch it, but people still use it and probably will. Heck, people
> still use 'ifconfig'...
>
> > I thought it was a good idea then, but passing
> > messages from userspace to the kernel and then to userspace again is really a
> > waste of time.
>
> It's not happening a lot so it's not a waste of *much* time ;)
>
> > NetworkManager already uses wpa_supplicant to avoid all the
> > nasty details of dealing with wireless configuration, so why not keep using
> > it for everything instead of hiding wpa_supplicant behind nl80211?
>
> I hope that nm would start using nl80211 instead of talking to
> wpa_supplicant and just start wpa_supplicant if necessary. Or maybe some
> startup scripts start the userspace MLME (wpa_supplicant) for the
> interfaces during boot/hotplug.
NM uses wpa_supplicant for 3 basic things:
1) configuration of an 802.11 connection
2) getting scan results
3) WPA/802.1x
wpa_supplicant doesn't separate the configuration/setup of an interface
from the 802.1x stuff, mainly because it has to do things like derive
keys and push them down to the driver at specific times. These two
functions are pretty intimately related. And since NM needs WPA
support, it uses wpa_supplicant for the 802.1x/WPA stuff. The only
stuff left is open & static WEP, which wpa_supplicant also handles. So
it was a no-brainer to push all the wireless config to wpa_supplicant
and have NM just feed wpa_supplicant the config info.
NM now gets its scan results from wpa_supplicant because drivers used to
get (and some still do) very confused when multiple processes would
request scans and get results. There was a nice race between
wpa_supplicant and NM in some drivers (airo in particular) where
wpa_supplicant would request a scan, and the driver would signal
results, but by the time NM saw the event and requested the results,
wpa_supplicant had already consumed them. This was "fixed" by making
drivers age scan results like ipw2x00 over a number of scans and not
erasing them right away after the scan was done.
I like pushing most of the config stuff to wpa_supplicant, because that
basically means that all of that is in _one_ project. When
nl80211/cfg80211 land and start getting adopted, that means that only
_one_ of {NM, wpa_supplicant} needs to get ported over, instead of two.
Dan
> > This is
> > more simple and direct and allows the kernel to expose exactly what the
> > hardware/kernel can do. Userspace won't have to change much and nl80211 won't
> > have to support every possible thing a userspace MLME would want.
>
> It's not that the kernel will have to support everything that a
> userspace MLME would want, but rather that the kernel needs to support
> everything the MLME would want, to support fullmac drivers.
>
> Another counter: when you have a tool like 'iw' that David wrote, then
> it'll need to look for the userspace MLME every time you invoke it and
> start communicating with it instead of the kernel. That's likely a waste
> of much more time than just bouncing the messages.
>
> johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
