cfg80211 configuration vs. actions

cfg80211 configuration vs. actions

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

Hi,

After some consideration I've been thinking that cfg80211 really should
be changed a bit. I'm trying to think of what we need at this point.

Right now, I have a ->set_config() call for each netdev which sets a
whole bunch of configuration parameters. But we said in London that
changing e.g. the SSID should not actually trigger any association right
away.

So now when only ->associate() actually makes the configuration take
effect, we'll need to have
 * a way to know what configuration is "pending"
 * a way to get the configuration that is "active"

That's fine. But why would we want drivers to handle it? Obviously,
drivers are going to need to handle the ->get_association() which
currently returns the current BSSID but should also return all the other
parameters.

However, cfg80211 could, with some hand-holding from the driver via
->get_config_valid() handle the whole issue of keeping the "pending"
config, and then pass it to the driver for ->associate(). ->get_config()
and ->configure() get dropped completely.

Another thing is... For ->reassociate(), which config to use? "re" seems
to imply to use the previous one, but people might also expect it uses
the new one. Maybe we should just refuse reassociate with some
well-defined error code (e.g. -ESTALE) in the cfg80211 itself when the
configuration has been changed? That might help networkmanager and
wpa_supplicant when a user interferes with it.

{Luis: this enables configfs support without that transaction layer in
configfs because we have our own transaction layer now}

{as another side effect, this allows us to implement wext compat much
easier}

Does that make sense?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]