On Tue, 2011-04-05 at 11:05 -0700, Javier Cardona wrote: > We would like to preserve the ability to join an open mesh without a > daemon, in the same way that a station can associate with an AP > without one. Keep in mind that even the station case on an open or WEP network is pretty useless since it will not reconnect if the connection drops, or do any sort of roaming. > With that goal in mind, the alternatives are to > duplicate the MPM in userspace or to reuse the in-kernel MPM with only > AMPE in userspace. Considering that AMPE uses MPM frames and state > machines, reusing the in-kernel MPM is a significantly lower effort > alternative. Furthermore, while working on AMPE we can also bring the > in-kernel MPM up to spec. > Of course this requires agreeing on a suitable API between MPM and > AMPE. If you don't like the generic one I proposed we can try to > define a mesh-specific alternative. But first, setting aside the API change > proposal, do you object to this AMPE-in-userspace/MPM-in-kernel partition? After thinking about this more, yes, I think I do object. Not only is the design strange with passing frames back and forth, but also it seems like a rather slippery slope, at some point I fear somebody will attempt to "fake" MPM to take advantage of that kernel code even when it's not really fitting. Since practically speaking, wpa_supplicant is already required for almost everything, I don't see any real disadvantages to duplicating the MPM state machine there, and starting to deprecate the one in the kernel over time with new features only available in userspace one, maybe even removing it at some point. I realise this is a little more short-term effort, but I think the long-term benefit probably outweighs it. 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
