On Thursday 18 December 2008 22:22:34 Werner Almesberger wrote: > So, first of all, given that TX power is controlled only indirectly > anyway, should we implement rfkill control or not ? There is no kill > switch, so there would be no rfkill input. > > If the answer is "yes", would the following semantics be right for > the disabled state ? I think you should probably implement it. Rfkill is supposed to be a central place for userspace to turn the radios off. So if your radio doesn't register an rfkill device, it will result in inconsistent userspace state. Userspace (network manager, or whatever app) thinks that it disabled all radios, but it didn't, in fact. So yes, I think you should implement rfkill by stopping any TX actions immediately if it hits. The state callback would simply be emulated in software. > - we de-associate Rfkill is supposed to stop TX _immediately_. So no MAC cleanup, etc... > - we stop scanning > - all ioctls still work as usual, but they have no effect on > association and scanning until rfkill re-enables the device basically, yes. Note that current rfkill subsystem implementation is not that nice and you might get some headache from it. ;) -- Greetings, Michael. -- 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
