Johannes Berg wrote:
On Sun, 2009-05-31 at 21:01 +0200, Marcel Holtmann wrote:
You have a point there, but I'm not sure it even cares? When restarted
it will probably want to impose its current policy anyway? It would be
easy to add that we send the global default value for newly added ones
too but I'm not sure it's necessary -- Marcel?
we can be smart and send an additional CHANGE_ALL when opening the
control device if it is set. We can also just send these anyway. Doesn't
really matter? Does it?
Well, I don't think we want/need this.
See, Henrique says that the use case is Thinkpads which store the
previous state in the BIOS. But that matters to you only if you use a
mixture of operation systems, which we don't have to support.
"Other OS's" also includes the BIOS. My BIOS setup screen has an option
to toggle the wireless state. It's great to have this just work, and
annoying to have regressions.
And it's not a "mixture" of operating systems if you dual-boot linux,
but that will have the same problem. We'll get rather weird behaviour
if you dual boot A and B, where linux version A restores state to a
file, and linux version B uses the hardware persistent state.
On the other hand, people on machines that don't store the rfkill state
in the BIOS might care about having their machine boot up with the same
rfkill state(s) as they shut down with, so the sane thing to do would be
to have rfkilld store the state persistently, and then recover it at
boot. At which point the BIOS state becomes irrelevant and a detail we
actually end up not even _wanting_ to support because it means we need
to be aware of machine differences in userspace.
Complexity sucks, but I don't think this is irrelevant. I can see you
don't want to rely on the kernel for the default value (even though it's
controllable by module option).
I like one of the solutions Marcels suggested, that /dev/rfkill should
report the "global default values" only when they have been set - either
by userspace or by a platform driver.
Thanks
Alan
--
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
