On Fri, 27 Jun 2008, Dan Williams wrote:
> On Mon, 2008-06-23 at 17:46 -0300, Henrique de Moraes Holschuh wrote:
> > The current naming of rfkill_state causes a lot of confusion: not only the
> > "kill" in rfkill suggests negative logic, but also the fact that rfkill cannot
> > turn anything on (it can just force something off or stop forcing something
> > off) is often forgotten.
> >
> > Rename RFKILL_STATE_OFF to RFKILL_STATE_SOFT_BLOCKED (transmitter is blocked
> > and will not operate; state can be changed by a toggle_radio request), and
> > RFKILL_STATE_ON to RFKILL_STATE_UNBLOCKED (transmitter is not blocked, and may
> > operate).
> >
> > Also, add a new third state, RFKILL_STATE_HARD_BLOCKED (transmitter is blocked
> > and will not operate; state cannot be changed through a toggle_radio request),
> > which is used by drivers to indicate a wireless transmiter was blocked by a
> > hardware rfkill line that accepts no overrides.
> >
> > Keep the old names as #defines, but document them as deprecated. This way,
> > drivers can be converted to the new names *and* verified to actually use rfkill
> > correctly one by one.
> >
> > Signed-off-by: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
> > Cc: Ivo van Doorn <IvDoorn@xxxxxxxxx>
>
> Thanks for doing this!
>
> So with this patch, in the case where ex. hp-wmi advertises a killswitch
> and the wlan driver itself doesn't have one, when NM wants to softkill
> the radio, should NM do a SIOCSIWTXPOW or softblock the hp-wmi
> killswitch? Or would the wlan driver implement an rfkill handler and
I thought a lot about it, and I personally feel it is better to keep
SIOCSIWTXPOW separate from rfkill. This is a driver layer thing, and rfkill
doesn't care either way, but IMHO it is less confusing for the user if
iwconfig txpower doesn't change the rfkill status of a device.
This means NM would be trying to set the class/rfkill*/state to
RFKILL_STATE_SOFT_BLOCKED for the devices it wants to block.
And the way to be able to do it without going insane really is to start
adding rfkill subsystem support to all wireless network drivers, so your
WLAN devices will all have a rfkill class related to them.
> thus have /sys/class/rfkill/rfkillX as well? My understanding of what
> would happen here got buried in all the mails last time around. If the
> transmitter is not tied to a physical killswitch, but the killswitch is
> provided by another module (laptop specific driver for example), do we
> assume the rfkill state is authoritative or do we check each radio via
> it's own specific method?
Unless HAL can tell you about it, and you teach HAL the topology for every
laptop model (something I consider Not Doable), you really are supposed to
try to ignore as much as possible the topology of kill switches.
So, you add topology agnostic UIs to NM that let the user:
1. Easily try to set the state of all devices of a given type
2. Try to set the state of a particular device.
3. Try to set the state of all devices (shortcut to "for all types, do (1)
above).
hp-wmi's and thinkpad-acpi's softswitches would show up just like any
another device. The user would quickly learn that changing the state of
these devices has an effect of hardblocking others.
When I get to improving the interface to the global state (i.e. add the
attributes needed to implement rfkill-input in userspace), you will be
able to do more, or to do the above in an easier way.
--
"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-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
