On Mon, 2009-06-01 at 09:49 -0300, Henrique de Moraes Holschuh wrote: > 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'. I ... just don't understand what you're getting at. Are you talking about /dev/rfkill with or without the add-on I just sent a while ago? > > 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. Exactly. It never touched older devices, and ignored (well, it returned an error, but that was quite pointless) future attempts to set the default. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
