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. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
