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