On Wed, 26 May 2010 12:21:02 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
