Re: [PATCH 01/13] PM: Add wake lock api.

Rafael J. Wysocki
2009-02-13T22:52:40Z

On Friday 13 February 2009, Matthew Garrett wrote:
> On Fri, Feb 13, 2009 at 06:46:58AM -0800, Brian Swetland wrote:
> > [Matthew Garrett <mjg59@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