Henrique de Moraes Holschuh wrote:
On Sun, 06 Jul 2008, Tomas Winkler wrote:
From my experience from other OS the states of SW and HW RF KILL
switches should be independent and visible to user space
otherwise it's very hard to make something coherent out of it. It
should be visible to user himself so he/she knows what switch actually
press. And also to let say unmanned application, most important in
preserving SW switch state across reboots and resume/suspend events.
Radio state is just simple AND function of all the switches in the
game anything else just leads to confusion.
Currently we have rkill switch from sysfs, hw rfkill, iwconfig txpower
off, the last one is better to eliminate but still we have TRIPLE
BLOCKING
I am not convinced it is the best way to go, but I thought on it, and that
fourth state will at least help on sleep-to-ram resume, so you guys will get
four states.
But I can't give you a bitmap. Sorry, there is a stablished sysfs ABI in
mainline that says this:
00 - BLOCK ("off")
01 - UNBLOCK ("on")
I hate it, but I can't change it. We can *extend* it, but that's it.
Perhaps it's time to throw out the userspace interface and start over,
or at least replace it and emulate the old one, too.
I'm not even kidding. I have an iwl4965, and I've tried 2.6.25.10's
built-in driver and wireless-compat from a couple days ago. The rfkill
switch *works* but the userspace interface does nothing. (2.6.25.10's
module at least causes network-manager to notice that the interface went
down and gets a ton of "Requesting MAC access during RFKILL wakes up
NIC." Wireless-compat's driver just confuses network-manager.) The
rfkill module seems to have no effect, and 'find /sys -name *rfkill*'
shows nothing (other than the rfkill class and module). Rfkill doesn't
work on my ath5k system either (no rfkill file). This is Ubuntu Hardy,
which has nm 0.6, but I once tried nm 0.7 from svn and I don't recall it
working any better.
Not to mention the fact that I have both an rfkill switch and an rfkill
button. Pressing the button turns WLAN off (same RFKILL messages
spammed to dmesg) and Bluetooth *on*. Maybe it's thinkpad_acpi's fault,
but I don't really see how it's supposed to work right.
So it seems to me that the status quo is:
- If there's a sysfs file called rfkill, it has such and such
semantics, and you probably can't change it by writing to it.
- There probably isn't an rfkill file.
- Userspace, at least on my laptops, doesn't currently use the rfkill
ABI in any meaningful manner.
- Software rfkill control can easily do the wrong thing and there's no
obvious way to make it do the right thing from userspace, .config, or sysfs.
Maybe the new semantics should be something sensible with a read-only
file called "rfkill" that's backwards-compatible and shows the overall
state. Then we could do gnarly things like making *every* mac80211
driver have software rfkill control, add inotify or something to the
rfkill file, and generally have good and easily comprehensible control
over all radios. Hardware switches (and momentary swtiches and buttons
and whatnot) could all be exposed directly to userspace. Who knows --
there could even be files like "hard_rf_enable" (read-only, only there
if there's a readable switch, like on iwl4965) and "soft_rf_enable"
(read-write, unconditionally present), and a mechanism for userspace to
control the software part (i.e. userspace could tell rfkill-input to
stop doing anything and take control itself).
I'd suggest that nothing visible to userspace on the rfkill side go into
2.6.27 until it can be done right and it's clear what this whole
mechanism is supposed to do. I might even be talked into writing some
patches, because it would be kind of nice for all this stuff to work
right on my laptops.
If I'm missing something I need to make rfkill suddenly work on my
machine, please give me some hints, too :)
--Andy
--
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
