Hi 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. > > I wouldn't necessarily start with that. Hmm, true, converting wext isn't really needed first. Does making cfg80211 usable make a better candidate for first work? As far as I can tell, the only thing mac80211 implements for cfg80211 is interface creation / deletion... > > So that means, at least a PHY configuration command (am I missing > > something or is there none yet?) with attributes to specify channel & > > co. > > Oh, heh, that does indeed seem to be missing... I'd propose two additional commands: - NL80211_CMD_GET_WIPHY [_CFG] - NL80211_CMD_SET_WIPHY [_CFG] which would be invoked with a NL80211_ATTR_WIPHY and setting/getting NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_CHANNEL and NL80211_ATTR_PHYMODE. NL80211_CMD_RENAME_WIPHY could be dropped and replaced by NL80211_CMD_SET_WIPHY. There seems to be no "get name" command yet, so that will be covered too. (actually NL80211_CMD_SET_WIPHY would be backwards compatible with NL80211_RENAME_WIPHY since the latter is invoked with the same attributes) The NEWNAME notify-command could be renamed and used for channel / phymode notifications too. > Not sure what you mean here. The NL80211_CMD_ASSOCIATE command as I see > it is modeled after the 802.11 mlme interface, nl80211.h says: > > > * @NL80211_CMD_ASSOCIATE: associate with the given parameters > > * (%NL80211_ATTR_SSID is mandatory, %NL80211_ATTR_TIMEOUT_TU, > > * %NL80211_ATTR_BSSID, %NL80211_ATTR_CHANNEL, %NL80211_ATTR_PHYMODE, > > * and %NL80211_ATTR_IE may be given) > > Hence, here we also have the ability to set the phy mode/channel. We > still need an explicit command for that though for monitor interfaces. Yes, thats what I meant for interface configuration. However, I don't think NL80211_ATTR_CHANNEL and NL80211_ATTR_PHYMODE belong here - if something is capable of using more than one channel, it really should have more phys, not more interfaces... > Do I look dead yet? No way. Proprietary/custom driver extensions live in > debugfs. If you need something that's generally useful, we can add it to > nl80211/cfg80211, otherwise you get to feel the pain of having it in > debugfs. Ah, I didn't think of that. Full ACK. > Oh, I very much agree, nl80211 isn't frozen yet (except for that tiny > part that's in mainline already). And all of nl80211 API are the numbers > in the nl80211.h header file that userspace gets to see, so... Phew. The only thing nl80211.h contains in mainline is enum nl80211_iftype. So the possibility to make generic getter/setters out of the NAME commands is still there... David (Stephan: sorry, forgot to Cc: you) - 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
