Message-Id: <1211897317.22073.1255269155@webmail.messagingengine.com>
Date:	Tue, 27 May 2008 11:08:37 -0300
From:	"Henrique de Moraes Holschuh" <hmh@....eng.br>
To:	"Ivo van Doorn" <ivdoorn@...il.com>
Cc:	linux-kernel@...r.kernel.org, "Thomas Renninger" <trenn@...e.de>,
	"Dmitry Torokhov" <dtor@...l.ru>
Subject: Re: [PATCH 14/15] rfkill: do not allow userspace to override ALL RADIOS
   OFF

On Fri, 23 May 2008 16:15:33 +0200, "Ivo van Doorn" <ivdoorn@...il.com> said:
> On Thursday 22 May 2008, Henrique de Moraes Holschuh wrote:
> > What makes SW_RFKILL_ALL special, is that it is the kernel view of *The*
> > RFKill Switch.  SW_RFKILL_ALL is the event you get when the user
> > manipulates the very *thing* that created the "rfkill switch" term.
> 
> So do keys that are pressed that only send the KEY_WLAN, KEY_BLUETOOTH or
> KEY_UWB signals. They all indicate the key has been pressed and the
> radios
> should be turned on/off.

Indicate versus enforce.  There is a BIG difference there, and you can see it
even on how it was implemented by the laptop vendor.  The enforcing switch
has hardware behind it to make sure it works.  For the indication keys, you
are lucky if you get firmware that can make it work without the O.S.

> > You get that event when someone moves that slider switch in the side/top
> > of a laptop which has to kill all RF output in hardware as far as safety
> > regulations go.  Therefore, it refers to the only rfkill switch that has
> > guidelines that say that it must always work, and that it must not be
> > possible to override it in software.
> 
> That is a valid point, and rfkill is supposed to do that, but making
> a difference between RFKILL_ALL and the individual types is wrong
> because that won't result in a clearly defined expected behavior for all
> rfkill keys.

IMO, the big difference between regular KEY_* and RFKILL_ALL is that
RFKILL_ALL has EPO (emergency power-off) semanthics, while the others don't.

KEY_WLAN is usually easily overriden in firmware and software, vendors often
don't even bother to implement it in firmware, it is just software.  RFKILL_ALL
switches cannot be overriden at all in any hardware worth its weight, and they
work even if the entire system has gone out for lunch and is deadlocked.
That's quite a big difference.

The only reason I don't usually call the hardware rfkill switches "radio EPO
switches" is because they are not big, red, and shaped like a mushroom.  But
they are in fact required to act like one in airline regulations, AFAIK.  And
that certainly matches the good implementations of the hardware rfkill switch
I know of (they wire-kill the radios, not even firmware gets in the way).

So yes, I do feel RFKILL_ALL is different, and it warrants EPO semanthics in
the kernel, while all other rfkill events, such as KEY_WLAN, don't.

I don't feel strongly about not giving EPO semanthics to other rfkill events,
but I recommend against giving anything else EPO semanthics in rfkill.

> > Too bad that doesn't apply to "removable" radio transmitters, like
> > PCMCIA and ExpressCard WLAN cards, USB RF transmitters, and so on...
> > probably, the user is expected to yank them off when he moves the switch
> > to the "no radios working here!" position.  Well, we can do better.  We
> > can make it apply to these other radio transmitters, too.
> 
> Through the write-only rfkill class right? ;)

More like through the new read-write/write-only rfkill class, since you have
already ACKed those patches, but yes :-)

> > IMO, "kill ALL radios" events are is the only kind of rfkill input event
> > that have to *always work*, even if something in userspace tried to
> > configure it not to.
> 
> Well the definition of "ALL radios" is the part that is the question,
> when the KEY_WLAN is
> pressed it would be "ALL WLAN radios" and should still have the same
> rules for allowing
> or disallowing userspace to overwrite the status.

Not really.  If you are concerned with a type, it is not an emergency situation,
nor is it a "you are entering a no-RF-emission area" situation.  There *IS* a
difference when a human decides to shut down EVERYTHING regardless of type, or
when he just wants the WLAN to stop wasting power but still wants Bluetooth up
so that he can listen to music on his wireless headphones.

And that notion carried over as the UI for circuit switches.  There IS a UI
notion behind "master switches", and it is very different from the notion behind
"sector switches".  And KEY_WLAN would just be a sector switch, with each 
wlan device being the room switch... while RFKILL_ALL is certainly The Master
Switch.

You will find this basic UI notion in *everything* dealing with an hierarchy of
switches: you have it on the power-grid and the mains input on your house, you
have it on your hydraulic pipes, and you have it in just about everything that
has not been bitten by the "standby" disease.  When you place a master switch in
"OFF" state, it bloody well *STAYS* *OFF*, and everything else after it is also
FORCED OFF, no matter what.

But of course, you have to make sure the master switch WILL bloody well stay off
when off by design.  You engineer it so that all possible failure modes will
cause it to go to the off state.

I would really appreciate that the rfkill class would abide to this UI notion for
the master rfkill events (*_RFKILL_ALL).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists