On 6/21/06, Michael Buesch <[EMAIL PROTECTED]> wrote:
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.
Michael, yes that was what I meant.
-
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
