On Friday 13 February 2009, Matthew Garrett wrote: > On Fri, Feb 13, 2009 at 06:46:58AM -0800, Brian Swetland wrote: > > [Matthew Garrett <mjg59@xxxxxxxxxxxxx>] > > > 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
