On Tue, 2009-06-02 at 09:38 +0200, Marcel Holtmann wrote: > If you really don't wanna have rfkilld _not_ impose a policy on cold > boot, then we can certainly add that. However that is part of rfkilld > and not the kernel. > > For global states, I am questioning the platform that actually has > storage for global states. All platforms that I have seen so far store > individual per device based states and not the global one. Yeah, unfortunately the platform drivers do store/restore global state. And in a sense that makes (made) sense since the default rfkill-input policy was to toggle everything based on the platform button. It's icky though. The problem with not telling rfkilld about this though is that the kernel will suddenly impose a hotplug policy that rfkilld doesn't know about. This might not even matter though since the _ADD will be sent with that policy already applied, and if it wants to change the policy rfkilld will do _CHANGE_ALL. > If you wanna just accept what the BIOS (or other OS) tells you then that > is an acceptable policy. So rfkilld will just map key input events in > that case. Fine by me. Question is if we can't do that right now? I > think we just can. Yes, we probably can do that right now, by making rfkilld start up without setting a policy (CHANGE_ALL). It just doesn't know what the policy is, then. > Question is if we really have a global state here. I doubt it since all > of these are device specific states. And having the BIOS or ACPI dictate > what state my external Bluetooth or WiFi device is in is pointless and a > total broken concept. Unfortunately that's how it worked before, it's part of the rfkill legacy that it seems we'll have to accept. I guess we have only ourselves to blame for not reviewing Henrique's rfkill implementation... > > You propose to exclude a feature that currently works, on the grounds > > that it is inherently broken. But you haven't said that this has ever > > caused incorrect behavior. All you have said so far is that it is a hack. > > This never worked so far. The mac80211 or Bluetooth subsystems have no > RFKILL state and thus global states are not enforced. An external dongle > without RFKILL support is not taken into account. You are not talking > about global states here. They are all device specific. The device just > happens to be a platform device builtin the system. Right, but rfkill does actually have a function to set the global policy state (rfkill_set_global_sw_state) which some platform drivers insist on calling. The only reason we would need the NVS_REPORT then is to detect whether or not anything in the kernel called rfkill_set_global_sw_state(). If we can live with just configuring rfkilld for the (arguably broken) case where somebody cares about this, I'm happy with removing it. Hope that helps clear up your confusion. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
