signalling suspend/resume events (deviceKit-power)

[Dan Williams]

On Tue, 2009-12-08 at 22:18 +0100, Anders Lund wrote:
> Dan Williams skrev:
> > On Tue, 2009-12-08 at 16:57 +0100, Anders Lund wrote:
> > > Dan Nicholson skrev:
> > > > Dan Williams really wanted the kernel to send a resume event so we
> > > > could get rid of the broken NetworkManager dbus-send signaling from
> > > > pm-utils. Maybe this would work.
> > >
> > > Why is that broken? And it is a (blocking) method call, or is that the
> > > broken part? From a user perspective, it appears that networkmanager
> > > disconnects before the suspend, and connects after the resume.
> > >
> > > In any case, the best/safest/most correct solution is of course
> > > preferable :)
> > 
> > Not necessarily the /kernel/, but something like DK-power/upower that
> > handles the policy.  The point was more to make NM aware of
> > suspend/resume so that we can do more intelligent things with it,
> > instead of having scripts somewhere else poke NM in response to random
> > events.  The other issue was the dbus for a long time was broken and
> > short-lived dbus-send invocations would get lost in the bus.  This has
> > been fixed since July of this year in dbus though.
> > 
> > It just seems like a cleaner model if NM is the thing that listens for
> > the event and responds to it, since NM knows what it needs to do for
> > suspend/resume.  Instead of having all the scripts that handle
> > suspend/resume "over there somewhere", disconnected from the thing
> > that's actually performing the actions.
> > 
> > Dan
> > 
> 
> But then, this IPC - what dbus is meant to do, iiutc :)
> 
> Of course if there was a message directly from devicekit-power, that would be 
> cleaner and easier to use for developers.
> 
> Then there is also the quiestion of sync, mentioned earlier in this thread. It 
> may be nessecary for some applications to do their preparations before 
> suspend. 
> 
> For Network manager, it would be cool if, when I close the lid and move to 
> another location, it would not try to recreate the old connection without 
> looking for available ones first (I'm not sure about what actually happens 
> with current nm, I do not move my laptop around much this time of the year)

NM doesn't do this.  If suspend/resume are working properly NM will
start from a clean slate.  There were two problems in this area:

1) the dbus bug that caused dropped messages for short-lived processes
(since fixed in dbus); this caused the dbus-send scripts from pm-utils
never to deliver their message to NM.  The hack was to add --print-reply
to the pm-utils scripts to ensure that dbus would send the message to
NM.  You can verify this by checking to see whether NM says
"sleeping..." and "waking up..." when suspending/resuming.

2) crappy drivers preserving the scan list over suspend; this was fixed
in the mac80211 stack and ipw2x00 in 2.6.29 or 2.6.30.  NM throws away
the scan list on suspend; but when resuming, the driver would return the
pre-suspend scan list, making it look like your AP was still there, no
matter if you were 100 miles away and a week later.  If you're using an
out-of-tree or staging driver, there's not much NM can do here; use a
better driver.

Dan