Re: [PATCH 1/8] PM: Opportunistic suspend support.

Neil Brown
2010-05-27T07:35:22Z

On Wed, 26 May 2010 12:21:02 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote:
> > > With a single suspend manager process that manages the suspend state you
> > > can achieve the same goal.
> > >
> >
> > Yes we don't need the /dev interface, but it is useful. Without it any
> > program that needs to block suspend has to make a blocking ipc call
> > into the suspend manager process. Android already does this for java
> > code, but system processes written in C block suspend directly with
> > the kernel since they cannot use the java APIs.
>
> So provide a C interface to it as well?
>
> Surely you can have the java thing have a unix socket or something a C
> app can talk to. That shouldn't be hard at all.
>
> Or make the suspend manager a C proglet and provide a JNI interface, or
> whatever.

I fail to understand the modern fascination with complex IPC mechanisms.

If you have a userspace process that initiates suspends, and you want other
user-space processes to be able to block that suspend, then I would suggest
the use of a lock-file. /var/run/suspend/blocked maybe.

To block suspend, you open the file and get a read lock.
To initiate a suspend you take a write-lock (blocking if necessary), then
ask the kernel to suspend.
To restrict access to particular users you use permissions - either group
based or ACLs (or both).
This is all easy to do from C or python or perl or presumably even java..
(I use this mechanism on my Freerunner and even have shell scripts that
happily prevent suspend).

NeilBrown