Dnia 4 stycznia 2010 0:30 "Rafael J. Wysocki" <rjw@xxxxxxx> napisał(a): > On Sunday 03 January 2010, Bartłomiej Zimoń wrote: > > Dnia 3 stycznia 2010 22:29 "Rafael J. Wysocki" <rjw@xxxxxxx> napisał(a): > ... > > > > It could be even UIO module but there are no pm events reachable there? > > > > If it is not clean, we must extend pm-utils or write something new > > (with backends dbus, ipc, scripts, ...) > > But You see? We still have no information from kernel about events > > (especialy resume) or maybe i dont see this ;/ > > They are available to the process that tells the kernel to suspend. > > Namely, to tell the kernel to suspend to RAM, the process (call it a power > manager) needs to (for example) fprintf() "mem" to /sys/power/state. As soon > as this happens, the kernel will start to freeze processes (except for the > power manager itself), so the power manager knows that everything should be > ready for the suspend before it writes to /sys/power/state. It doesn't need > the kernel to tell it when the suspend is going to start, because it _knows_ > that in advance. > > Now, the fprintf() used to trigger the suspend will not return until the resume > is complete. So, again, when the fprintf() returns, the power manager will know > that the resume has just finished (more precisely, the kernel side of it has > just finished). > > There simply is no need for any special communication between the kernel and > the power manager. > Thx Rafael - now it clear to me. And what do You think about sending extra signals to processes? Best regards. Bartłomiej Zimoń PLD Linux, Kadu Team, FreeRunner user http://kadu-im.blogspot.com/ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
