mac80211 MLME and user space

mac80211 MLME and user space

[Andy Johnson]

Hello,
I am trying in the last days to delve into the Linux kernel wireless stack and
  I have a really short question (nevertheless,  please consider
giving a detailed and long answer); in the
linux wireless site, it says:
"Right now the MLME is done in the kernel for station mode (STA) and
userspace for AP mode (hostapd) but our goal is to eventually move it
to userspace completely."

see: http://linuxwireless.org/en/developers/Documentation/mac80211

My question is : why?

What are the benefits of moving MLME to user space ? why not to do the
opposite, namely
move the MLME from user space (as in hostapd) to the kernel so it will
be solely in the kernel? Why not extend hostapd so it will be not in
kernel space at all but in kernel ?

As far as I understand, there is an objection for moving MLME to
kernel. For example,
I saw in a thread a few days ago:
"And there never will be since we don't want the whole AP MLME in the
kernel regardless of the driver." (Johannes Berg)
see:
http://marc.info/?l=linux-wireless&m=122657805527277&w=2

Regards,
AJhohnson

Re: mac80211 MLME and user space

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

[disclosure: I just got back home from debating club :)]

> My question is : why?

Let me first ask the opposite question: What value do you see in moving
more of the MLME, especially in AP mode, into the kernel? [1]

One of the most important arguments for putting the MLME into userspace
is "because we can". Remember that developing userspace code is much
simpler than kernel code, there's often no need to care about SMP
scenarios [2], memory allocations and stack size limitations etc.

Another important argument is that having this code in userspace makes
it a lot more replaceable, and allows experimentation with it. Consider,
for instance, new 802.11 working groups like 802.11r. Fast roaming,
specified by 802.11r, could, if we had the station MLME entirely in
userspace already, be implemented entirely in userspace. In fact, it is
(being) implemented there for experimentation. This is great for
multiple reasons: One, for the developer, it is much easier to test new
code in userspace, and if it crashes they can just go on working rather
than needing to reboot the test machine. Secondly, it allows deploying
that code to users much faster as it is almost always much easier to
replace a single userspace program than to replace the entire OS kernel.

Also, keeping things in userspace means that there can be competition in
that field. You can fork hostapd and use your own version for special
things without going to the hassle of patching the kernel every time. Of
course, right now the APIs are not entirely stable, but that would still
be much easier to follow.

johannes


[1] I don't buy the argument that this makes it magically more stable,
and yes, I've heard that before

[2] kernel code must consider SMP in almost all cases, while userspace
code can be written as a single thread

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mac80211 MLME and user space

[Michael Buesch]

On Tuesday 18 November 2008 21:16:49 Andy Johnson wrote:
> My question is : why?

It's really similiar to the questions:
Why do we have udev? Why didn't we fix devfs instead?
Or why is hotplugging in userspace?

It's all basically, because we don't _need_ to have it in the kernel.
Having it in userspace means much easier code (often no locking needed).
Having it in userspace means, it's easily runtime replacable. Even after
crashes.
Having it in userspace means exploitable bugs are less likely to affect
the whole system.
There probably are a lot more reasons to do this.

-- 
Greetings Michael.