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

[Neil Brown <neilb@suse.de>]

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