[linux-pm] [PATCH 01/13] PM: Add wake lock api.

Rafael J. Wysocki rjw at sisk.pl
Fri Feb 13 14:52:40 PST 2009


On Friday 13 February 2009, Matthew Garrett wrote:
> On Fri, Feb 13, 2009 at 06:46:58AM -0800, Brian Swetland wrote:
> > [Matthew Garrett <mjg59 at srcf.ucam.org>]
> > > The easiest way to handle this would seem to be a multiplexing daemon 
> > > that implements whatever policy a specific use case has. In your case 
> > > this would do its own reference counting and then implement timeouts for 
> > > specific applications, perhaps with some kind of acl so arbitrary apps 
> > > can't take a lock and then fall down a well. If you've got a 
> > > sufficiently advanced init then you'd be able to flag an application as 
> > > being in restart state and then have the daemon hold the lock until the 
> > > application chooses to reacquire it or not, which seems more flexible 
> > > than any purely kernel-based implementation.
> > 
> > It'd be nice to not have to indirect all userspace suspend inhibits.
> > If we had the device interface to userspace actually have INHIBIT
> > and STOP_INHIBIT ops, we could notice if the fd is closed without
> > actually returning the state to STOP_INHIBIT cleanly.  Add a mechanism
> > for waiting until somebody exits unexpectedly that init or your monitor
> > process could use, you avoid the indirection and have a mechanism for
> > handing over to whatever is responsible for restarting something that's
> > in an unhappy state.  Too convoluted?
> 
> Mm. How do you guarantee a timely handover? Doing it in userland means 
> that you can adapt it to work with whatever process restart setup you 
> have, whereas doing it in kernel means adapting whatever process restart 
> setup you have to the kernel. I'd still lean towards thinking that the 
> userland approach means you can have tighter integration with the rest 
> of your stack.

FWIW, I agree.

Thanks,
Rafael


More information about the linux-pm mailing list