Hi list, Hi Johannes, together with a friend of mine, I recently pondered about making linux wireless configuration utilities more friendly to use. He did some hacking to add wext to iproute2, but got "use nl80211" as reply. (cf. http://marc.info/?l=linux-netdev&m=117305184005985&w=2) However, nl80211 still isn't near any usable state. Worse yet, even the API is nowhere near sufficient for replacing wext. So I was wondering if anyone is working on this. (google pointed me to pynl80211, hence Cc: Johannes) As far as I understand, the first thing to tackle is converting everything to cfg80211 and making wext call cfg80211 functions, putting all the compatibility cruft into that layer while at it. This could be done incrementally, step-by-step, couldn't it? Or is there major restructuring planned? If not, I'd certainly like spending a bit of work on this (my time is as limited as everyone's, but I do have some wasted time here and there). However, a proper outline of the API needs to be thought of first. My very-humble totally-irrelevant opinion would be that nl80211 should provide all neccessary operations, only much more cleanly than wext ;). So that means, at least a PHY configuration command (am I missing something or is there none yet?) with attributes to specify channel & co. The "set association" command might be extended to work for interfaces. Proprietary/custom driver extensions could be handled as special attributes and/or special commands. (that explicitly excludes the PRISM2 cruft though, those are actually rather generic IMHO) Anyway, I'm hoping to start a little constructive discussion and planning here. Opinions? -David Lamparter P.S.: While I'm aware that changing kernel APIs is a very bad idea, I'm really thinking nl80211 isn't frozen yet. As far as I can tell, only iwspy and pynl80211 are using it at all. This hopefully won't end up as a compatibility nightmare AGAIN? - 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