Re: [PATCH 01/12] rfkill: clarify meaning of rfkill states

["Henrique de Moraes Holschuh" <hmh@hmh.eng.br>]

On Thu, 5 Jun 2008 18:03:42 +0200, "Ivo van Doorn" <ivdoorn@gmail.com> said:
> On Thursday 05 June 2008, Henrique de Moraes Holschuh wrote:
> > The correct reading of rfkill class states are:
> > 
> > RFKILL_STATE_ON:  transmitter is UNBLOCKED and *may* operate
> > RFKILL_STATE_OFF: transmitter is BLOCKED and will *NOT* operate.
> > 
> > Nothing else is correct.
> > 
> > We could certainly rename these states to
> > 
> > enum rfkill_state {
> > 	RFKILL_STATE_BLOCKED = 0,
> > 	RFKILL_STATE_UNBLOCKED = 1,
> > };
> > 
> > #define RFKILL_STATE_ON RFKILL_STATE_UNBLOCKED
> > #define RFKILL_STATE_OFF RFKILL_STATE_BLOCKED
> > 
> > Ivo, do you want a patch that does the above (plus the documentation
> > changes, of course)?
> 
> Patch would be good. I would however drop the #define RFKILL_STATE_ON
> and force the RFKILL_STATE_BLOCKED/RFKILL_STATE_UNBLOCKED usage
> to make sure everybody gets the right idea about the meaning.

The advantage of the former way is that we break nothing, and all drivers
can be moved to the new names at their maintainer's leisure.  It could also
work as a marker for "this driver has been reviewed and now uses rfkill
correctly" or somesuch.

-- 
  "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