Re: rfkill: how murderous can it be ?

[Dan Williams <dcbw@redhat.com>]

On Mon, 2009-01-12 at 17:15 -0200, Werner Almesberger wrote:
> I'd like to restart a discussion from last year, namely how aggressive
> an rfkill implementation is allowed to be when it comes to destroying
> MAC state.
> 
> The design suggested in rfkill.txt and also implemented in the existing
> drivers basically assumes a simple on/off switch that cuts power to the
> transmitter but doesn't change anything else. The question is if this 
> is already the full extent to which rfkill is allowed to affect MAC
> state or if it could go further.
> 
> In the AR6k, we don't have such a simple switch for the transmitter. We
> can control what the transmitter does very indirectly by temporarily
> reconfiguring the MAC, but this creates a fair amount of complexity,
> which also seems to be at odds with the design of rfkill.
> 
> Alternatively, we could just power down the whole WLAN module. That is
> easily done and very reliable. However, MAC state (ESSID, keys, and a
> host of other settings) is obliterated if we do this. A watchful user 
> space (e.g., wpa_supplicant) could then restore the status quo ante.
> 
> Now the question is whether this is still in the spirit of the design 
> of rfkill of if it would take things too far.
> 
> It seems that there is no consensus on this issue yet. I started the 
> implementation with the assumption that rfkill should always behave as 
> if it only cut transmitter power, so no other state of the MAC is
> allowed to be lost. This is also what Henrique suggested I should do.
> 
> However, Andy and recently Michael suggested that, given that an
> interface that has no connectivity for an extended period of time is
> likely to get reconfigured anyway, it may be sufficient if rfkill 
> leaves things in a state that allows user space to restore 
> connectivity, without having to worry about details beyond that.

Yes.  You have no guarantees about how long the RF is down when the
switch is flipped or the checkbox ticked.  Instead of putting a bunch of
complexity in the kernel and drivers that *already* has to be in
userspace, just punt it out to userspace where it's already done and
works well.

If there are any latency issues with this, then we need to fix those
latency issues in wpa_supplicant, not put complex state handling into
the stack drivers for this.  Treat rfkill the same as suspend/resume
from a state perspective, because they really have the same
consequences: you have no idea where you are when you wake up, what has
happened since RF was turned off, and whether your AP is still around.
Better to make scanning and associate fast and foolproof, which has to
happen in userspace anyway.

Dan