On Fri, 2006-06-23 at 10:20 -0400, Luis R. Rodriguez wrote: > On 6/23/06, John W. Linville <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 23, 2006 at 07:50:47AM -0400, Dan Williams wrote: > > > > > Our effort is probably better spent elsewhere, especially since many > > > popular userspace tools already handle resume for us just fine. More > > > useful to have drivers just come back from resume in an initialized > > > state similar to system boot. > > > > I think Dan makes a lot of sense here. Does anyone disagree? > > How would we handle resume() when using WPA, for example? Dan are you > suggesting we just bring up the driver clean and expect userspace to > have handled recovery from anything we were doing? This is important.
Well, for WPA you pretty much need a tool like wpa_supplicant to handle connections for you, otherwise there wouldn't be a reason for wpa_supplicant to exist. I don't think we really want a bunch of code in the driver to handle the reconnect cases, because this is exactly what wpa_supplicant already does and does well. I'm suggesting that instead of trying to stuff more logic in the drivers to handle reconnect on resume, that the drivers just come back from resume in the same state as system boot. They are initialized with default values and default state. They allow userspace tools that already know about policy and security to configure them, as these tools would do right after a system boot. We can't assume that policy and security are exactly the same as before sleep. > Or should we just expect the driver to re-set all settings again and > expect wpa_supplicant to pick up well where it left off? If sysfs will > get cleared after resume then there is no point in using it, but if > its stateful after suspend then this is where I suspected > wpa_supplicant could make use of sysfs. Perhaps there is a better way > -- what I suggested was just an idea while we discussed resume/suspend > in another thread. The reason I started a new thread was I figured > configfs/sysfs could be used for other things as well. I don't know that you can really "pick up where it left off" in many cases. Again, the system can be moved, access points can go away, more networks can appear, and WPA is just more complicated than WEP. You simply cannot expect a driver to return to its exact pre-sleep state when using stuff like 802.1x/WPA[12] Enterprise. What if your session keys expired while you were sleeping, for example? Besides, userspace tools like NetworkManager and wpa_supplicant are just going to overwrite the config settings the driver restores anyway, since you need to do another scan, check results, and set the connection back up after accounting for stuff that may have changed. Blindly attempting to connect with all the old settings doesn't make much sense. It's an optimization to have the driver restore settings, and it might make things a second or three quicker in some cases, but in many other cases it's completely useless to do this, possibly detrimental. I don't see the overall benefit right now. We've got better things to do with drivers at the moment. Dan - 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
