Re: [PATCH] rfkill: create useful userspace interface

[Alan Jenkins <alan-jenkins@tuffmail.co.uk>]

Johannes Berg wrote:
> On Sun, 2009-05-31 at 21:01 +0200, Marcel Holtmann wrote:
>
>   
>>> You have a point there, but I'm not sure it even cares? When restarted
>>> it will probably want to impose its current policy anyway? It would be
>>> easy to add that we send the global default value for newly added ones
>>> too but I'm not sure it's necessary -- Marcel?
>>>       
>> we can be smart and send an additional CHANGE_ALL when opening the
>> control device if it is set. We can also just send these anyway. Doesn't
>> really matter? Does it?
>>     
>
> Well, I don't think we want/need this.
>
> See, Henrique says that the use case is Thinkpads which store the
> previous state in the BIOS. But that matters to you only if you use a
> mixture of operation systems, which we don't have to support.
>   

"Other OS's" also includes the BIOS.  My BIOS setup screen has an option 
to toggle the wireless state.  It's great to have this just work, and 
annoying to have regressions.

And it's not a "mixture" of operating systems if you dual-boot linux, 
but that will have the same problem.  We'll get rather weird behaviour 
if you dual boot A and B, where linux version A restores state to a 
file, and linux version B uses the hardware persistent state.

> On the other hand, people on machines that don't store the rfkill state
> in the BIOS might care about having their machine boot up with the same
> rfkill state(s) as they shut down with, so the sane thing to do would be
> to have rfkilld store the state persistently, and then recover it at
> boot. At which point the BIOS state becomes irrelevant and a detail we
> actually end up not even _wanting_ to support because it means we need
> to be aware of machine differences in userspace.
>   

Complexity sucks, but I don't think this is irrelevant.  I can see you 
don't want to rely on the kernel for the default value (even though it's 
controllable by module option).

I like one of the solutions Marcels suggested, that /dev/rfkill should 
report the "global default values" only when they have been set - either 
by userspace or by a platform driver.

Thanks
Alan