On Wednesday 21 June 2006 17:08, Luis R. Rodriguez wrote: > On 6/16/06, Stefan Rompf <[EMAIL PROTECTED]> wrote: > > Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch: > > > > I think the most important question is how a suspend/resume action should be > > translated. For the managed case, it is clearly an association loss, > > normally > > signalled by netif_carrier_on/off() and a corresponding SIOCGIWAP event. > > Supplicants can act on this. In AP mode, suspend is equal to disassociating > > all stations. Ad-hoc... dunno. > > > > For a softmac stack like devicescape, it makes sense to have a function that > > abstracts these scenarios as it is the stack anyway that handles association > > stuff. However, I'd rather extend the existing function > > ieee80211_netif_oper(). > > Since d80211 is already being patched for sysfs how about we use sysfs > (and kobjects) to maintain the state at suspend() and resume(). This > would allow userspace tools like supplicant running in the background > to pick up from sysfs where it left off and for our drivers to save > where we left off. ieee80211_hw can then just refer to their suspend() > and resume() routines from its respective struct pci_driver or struct > usb_device.
Ok, so you mean we remove the full responsibility to recover a connection from the driver resume() handler and let a userspace daemon keep track of this? So basically stay with the current implementation of suspend() and resume() in the drivers and assume userspace does the right thing and detects a resume and recovers connections and so on? Did I understand that right? If yes, I think that's a very nice idea, too. Probably the best. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
