Hi David, > Hmm, true, converting wext isn't really needed first. Does making > cfg80211 usable make a better candidate for first work? Yeah, I think so. > As far as I can > tell, the only thing mac80211 implements for cfg80211 is interface > creation / deletion... Yes, that's true. But cfg80211 also doesn't implement that much more of nl80211 right now. > 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. Hmm, this does seem to be orthogonal, for example changing the channel could be accepted but changing the name could fail. Hence, it doesn't make sense to use all these attributes together. IMHO adding commands isn't a problem, so I'd rather see RENAME_WIPHY stay while adding a command to switch channels. Something like SET_CHANNEL(CHANNEL,PHYMODE). > The NEWNAME notify-command could be renamed and used for channel / phymode > notifications too. Again, these two are orthogonal and I'd rather see them split. > 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... I don't understand this comment. The CHANNEL/PHYMODE attributes are used with associating as per the 802.11 mlme interface. Yes, if you support multiple channels/PHYs then you should have multiple wiphys, but that doesn't preclude allowing to set the channel/phymode in the same command as changing the association, no? > 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... Right, that was needed to get cfg80211/mac80211 with virtual interfaces to compile. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
