Re: rfkill-input madness

[Johannes Berg <johannes@sipsolutions.net>]

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

On Mon, 2009-03-30 at 14:21 -0300, Henrique de Moraes Holschuh wrote:

> Here's what is (was :-) ) in rfkill-input:

Heh :) I've been refactoring rfkill-input too -- but I haven't actually
changed it.

> 1. There are per-type global switches (and no "all" switch)
> 2. There is a flag, EPO (emergency power off).
> 
> rfkill-input translates any "EV_SW SW_RFKILL_ALL ACTIVE" events into "enable
> EPO".  It saves the states of the switches beforehand, so that it can
> optionally restore them.
> 
> When something enables the EPO, all switches go into block.  And they refuse
> to go out of block until the EPO flag is cleared.   I.e. it has the proper
> semantics for a safety device.
> 
> What happens when you clear EPO isn't much.  The rfkill core doesn't care
> much, all that it knows is that switches are not prohibited to go out of
> block anymore once the EPO flag is clear.
> 
> rfkill-input, OTOH, can be configured to do one of three things when it gets
> "EV_SW SW_RFKILL_ALL INACTIVE":
> 
> 1. just clear the EPO flag (the user will have to go and manually unblock
> the switches through sysfs or normal events that rfkill-input processes)
> 
> 2. clear the EPO flag, and restore the global switches to the state previous
> to the EPO
> 
> 3. clear the EPO, and unblock all switches.

Ok, that makes sense, and I think I understood this much already from
cleaning out rfkill-input.c (which killed a few dozen lines of code w/o
any functionality changes)

> So, there is NOT an "all" switch.  But there is the handling of the
> SW_RFKILL_ALL event by rfkill-input.
> 
> > > I can't say I strongly want it, since I am happy enough with rfkill-input,
> > > though.  But the API to userspace _is_ incomplete if the global states and
> > > global functionality are not exposed.
> > 
> > I've kinda removed the entire userspace API part from rfkill, mostly out
> > of laziness (so I guess I'll add it back) but also because I don't quite
> > see the point. Has anyone come up with a usecase for it?
> 
> I'd talk that over with our Network Manager maintainer, he is the one who
> might want it.

As far as I understood him (he was giving an example), Dan doesn't care.
But let's ask :) (CC'ed)
Dan, would you want to have NM control rfkill from userspace, instead of
using rfkill-input?

johannes

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