Re: rfkill-input madness

Johannes Berg
2009-03-30T17:30:16Z

[-- 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?