WLAN status update

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> It seems like it is turning off ieee80211 powersaving mode (the AP
|> beacon dropbox system) in order to have that kind of impact.
|
| You mean the synchronized wakeups ? Yes, it could be that.
|
|> I don't think rfkill itself has much expectation except to stop the
|> transmission action.  It doesn't care how we're doing that or what
|> residual power is pulled at DC.
|
| The expectations are as follows:
|
| - explicitly, it has to be bullet-proof. rfkill attempts to achieve
|   this reliability through simplicity (i.e., just "throw a switch"),
|   but our interface to the firmware is way more abstract.
|
| - in the discussion on linux-wireless, Michael Buesch also mentioned
|   that rfkill is expected to act "immediately".

Yeah I take it to mean when you return from the rfkill action, the
stopping of RF TX is done already.  That sounds doable?

| - implicitly, rfkill is also not expected to mess up any other
|   configuration, but the documentation doesn't state this (yet).
|   This follows naturally if you assume that what you have is a simple
|   switch, but if you don't, these are not trivial semantics. (I.e.,
|   the closes thing the original Atheros code has, --wlan disable,
|   does interfere with concurrent configuration.)

Well killing TX kills association, kills any connectivity lying around,
etc.  It inherently affects everything on top of the network interface.
~ I think maybe we can just do it and the sky won't fall?

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklrCOQACgkQOjLpvpq7dMr85QCfaH51DfZ0SD+zUJ59KKqxgWc5
NagAn2+W6ob6FLoFdWV32BkAYUndHez6
=cD44
-----END PGP SIGNATURE-----