On Mon, 01 Jun 2009, Johannes Berg wrote: > > Just don't expose a rfkill type until the first rfkill structure of that > > type gets registered. THAT closes all holes in a sensible, > > principle-of-least-suprise way. The current code (including the rewrite) > > already deals with defaults and firmware-backed state storage just fine in > > that case. All you need is a full interface that deals with global state > > hotplug (which ain't difficult, that's one or two more notifications only). > > Global state hotplug is just not really possible to support, and I don't I used 'expose' for a reason. You don't expose them to userspace until there is an user for that type. You don't even have to hide it again after the last user gets unregistered... That's not hotplug as in 'create a new rfkill type for the kernel'. > think even your original code supported that, since it cannot affect > previously registered rfkill instances. You definitely don't want to > hotplug a wireless device and turn off all others "due to that". You do recall how the 'override system default' machinery worked? It would return an error if a rfkill struct of that type had already been registered, or if a call to set the default for that particular rfkill type had already happened. -- "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