Ok, here are my thoughts on why alternative one is best. To recap, these
are the alternatives I see when configuring the userspace MLME (copied
from the wiki as I just wrote it there):
Userspace MLME configuration (alternative 1)
nl80211 nl80211
{ nm | iw } -------------> { cfg80211 } -------------> { umlme }
Userspace MLME configuration (alternative 2)
nl80211
{ nm | iw } -------------> { umlme }
Userspace MLME configuration (alternative 3)
socket (*)
{ nm | iw } -------------> { umlme }
Currently, we have alternative three being used by nm and wpa_cli to
configure wpa_supplicant via the control socket.
As I said before, I favour alternative one, for the following reasons:
1) it is transparent
Alternative one means that the userspace tools do not need to know
whether a userspace MLME is used or not. It is completely transparent,
the regular command line tools can be used, tools that need to scan with
certain parameters can just request a scan via the regular mechanism and
expect results.
2) it helps us define the interfaces
With more processing power becoming available in smaller form factors
and more MLME features required by new networked appliances like
cameras, washing machines etc., I expect that full-mac chipsets will
start to become more common again. Especially mesh-networking like used
in the XO may be a push for this. However, it is not clear that
everybody will have drivers for such hardware. Defining the full
interface to the MLME in terms of nl80211 even when most of the MLME is
implemented in userspace allows us to experiment with the full MLME
interface even though we don't always have full-MAC chipsets or drivers
available to experiment with.
3) it is UMLME-agnostic
The current control socket implemented in wpa_supplicant was designed
specifically for wpa_supplicant and much more for the actual WPA
features than all the MLME features. I don't want to say that it is
ill-defined or badly documented, neither seems to be the case, but I do
think that it being defined for wpa_supplicant could be a stumbling
block when you want to implement it within another UMLME.
4) it can support wext
Since we go through the kernel, we can introduce a thunking layer that
makes wext->nl80211 conversions for the userspace MLME and the other way
around for the results. This requires some work and also requires making
wext not take the RTNL so a userspace MLME can't block the RTNL, but is
certainly possible and makes the userspace MLME even transparent to
legacy tools.
Arguments two and three really speak for both alternatives one and two,
while one and four are unique to alternative one.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
