[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111008221439.48f30263@notabene.brown>
Date: Sat, 8 Oct 2011 22:14:39 +1100
From: NeilBrown <neilb@...e.de>
To: markgross@...gnar.org
Cc: linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
Alan Stern <stern@...land.harvard.edu>,
amit.kucheria@...aro.org, farrowg@...ibm.com,
"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
linux-pm@...ts.linux-foundation.org, khilman@...com,
Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
peterz@...radead.org
Subject: Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend
blocking (aka more wakelock stuff)]
On Sun, 2 Oct 2011 09:44:56 -0700 mark gross <markgross@...gnar.org> wrote:
> resending to wider list for discussion
> ----- Forwarded message from mark gross <markgross@...ngar.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@...ngar.org>
> To: linux-pm@...ts.linux-foundation.org
> Reply-To: markgross@...gnar.org
> Cc: arve@...roid.com, markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>, amit.kucheria@...aro.org, farrowg@...ibm.com, "Rafael J. Wysocki" <rjw@...k.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
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists