On Tue, 13 Jan 2009, Matthew Garrett wrote: > On Mon, Jan 12, 2009 at 05:15:14PM -0200, Werner Almesberger wrote: > > Alternatively, we could just power down the whole WLAN module. That is > > easily done and very reliable. However, MAC state (ESSID, keys, and a > > host of other settings) is obliterated if we do this. A watchful user > > space (e.g., wpa_supplicant) could then restore the status quo ante. > > Some platform rfkill methods will perform a logical PCI hotplug of the > device, without any means of notifying the driver beforehand. Since this > will destroy the driver structure, I think we really need to leave state > restoration up to userspace. Sounds acceptable, certaily... But I DO heavily suggest that we inform userspace differently when state was lost (i.e. when it absolutely HAS to reconfigure the device or there are no chances of data passing through). Right now, it HAS that information in a roundabout way: if the device disappears (hotunplug), state was lost (duh! :-p) If it stays around, no state was lost... And, as an user, I'd be rather annoyed if suddenly I couldn't easily and cheaply just hit the rfkill hotkey (softswitch) to kill and unkill my WLAN while browsing, and stopping a few minutes to read the screen... because every time I unkilled, the system would churn, deassociate and reassociate and be otherwise annoying doing a reconfiguration it didn't absolutely have to do. In other words: make it possible to be configurable! From the kernel POV that just means we need to have to publish to userspace the fact that it has to reconfigure when there is not a full hotunplug/hotplug being done. -- "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
