WLAN status update

Andy Green andy at openmoko.com
Mon Jan 12 11:15:27 CET 2009

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> Yeah I take it to mean when you return from the rfkill action, the
|> stopping of RF TX is done already.  That sounds doable?
| We could introduce a synchronization point (currently, there's none
| for this kind of operation). This would make sure that the command
| has at least started by the time we return. I'm not sure if rfkill
| actually cares about this, but it seems like a good idea anyway.
|> 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?
| It's things like whether rfkill is allowed to reset the ESSID or
| what should happen if you try to change the ESSID while rfkill is
| in force. ESSID is just a prominent example. There's plenty more
| parameters.
| Anyway, you don't need to convince me that it would be pleasant
| if all this was in fact nice and simple ;-)

Well I am sure it is not that trivial to implement.

But is the multiweek stall for imagined total perfection on the detail
of what it impacts from day 1 ever going to pay anything back?  Or would
it have been better to just do it and refine it (eg stash / restore
essid) if trouble is seen.

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


More information about the devel mailing list