Re: [markgross@thengar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Sun, 2 Oct 2011 09:44:56 -0700 mark gross <markgross@thegnar.org> wrote:

> resending to wider list for discussion
> ----- Forwarded message from mark gross <markgross@thengar.org> -----
> 
> Subject: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)
> Date: Tue, 20 Sep 2011 13:33:05 -0700
> From: mark gross <markgross@thengar.org>
> To: linux-pm@lists.linux-foundation.org
> Reply-To: markgross@thegnar.org
> Cc: arve@android.com, markgross@thegnar.org, Alan Stern <stern@rowland.harvard.edu>, amit.kucheria@linaro.org, farrowg@sg.ibm.com, "Rafael J. Wysocki" <rjw@sisk.pl>
> 
> The following patch set implement an (untested) solution to the
> following problems.
> 
> 1) a method for making a system unable to suspend for critical sections
> of time.

We already have this.  A properly requested suspend (following wakeup_count
protocol) is unable to complete between wakeup_source_activate() and
wake_source_deactivate() - these delimit the critical sections.

What more than this do you need?

If user-space wants to prevent suspend, it just needs some sort of protocol
for talking to the user-space process which follows the correct protocol to
initiate suspend.  That isn't a kernel problem.

> 
> 2) providing a race free method for the acknowledgment of wake event
> processing before re-entry into suspend can happen.

Again, this is a user-space problem.  It is user-space which requests
suspend.  It shouldn't request it until it has checked that there are no wake
events that need processing - and should use the wakeup_count protocol to
avoid races with wakeup events happening after it has checked.

i.e. there is no kernel-space problem to solve here (except for possible
bugs).

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]