[lkml]   [2011]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
On Mon, 17 Oct 2011, NeilBrown wrote:

> .... Actually, the more I think about it, the more sense it makes to include
> the wake-up-at-time service with the suspend-daemon. Then the RTC alarm
> doesn't need a wakeup_source.
> So my hypothetical suspend-daemon provides 2 services:
> 1/ Client can say "Don't suspend after X". If X is in the past it means
> don't suspend at all. In the future it means "If you suspend before
> this, be sure to wake up by X". This request must be explicitly
> cancelled (though some mechanism is needed so that if the process dies
> it is automatically cancelled).
> 2/ Client can say "check with me before entering suspend". Client needs to
> respond to any callback promptly, but can register a "don't suspend after
> now" request first.
> (Client probably gets a callback both on suspend and resume)

1/ can be a separate type of communication channel to the daemon. The
client opens a connection and sends the time X. It then blocks waiting
for a response. The daemon waits until X (using RTC wakeup alarms as
necessary), then acknowledges the request and prevents further suspends
until the connection is closed.

2/ is the normal client communication mechanism that I described
earlier. I don't see why a callback would be needed during resume in
general, although some clients might want to be informed.

Alan Stern

 \ /
  Last update: 2011-10-17 17:45    [W:0.126 / U:0.344 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site