Re: nl80211 status? (implying cfg80211 status)

[David Lamparter <lists@diac24.net>]

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)