# Garrett D'Amore 2006-06-22:
> Peter Seebach wrote:
> > > [... suspend should fail when device can't suspend ...]
> > I'm not sure of this.  I think in some cases I'd rather be able to
> > force a suspend.  I might be happier keeping my files and losing
> > audio until I reboot
> > than having a machine potentially lose data because I can't suspend it.
> 
> In the _real_world_, the problems that can create a failure to suspend
> are often temporary.
> 
> [... high end systems need suspend too ...]
> 
> A lot of times a device will say "I'm sorry, I can't suspend right now. 
> You can either correct this condition by doing X, or you can try again
> later."

What about allowing suspend to sleep, and return error only if the cause
is permament or "something just broke"?

> Having a "force" can be optional as well, but it should not, IMO be the
> default.
> 
> Btw, I think it is also true that there should be a facility for
> userland processes to reject a suspend.  I.e., imagine a real-time
> process that is controlling a device over an RS-232 link (maybe writing
> a firmware update to the device).  In such a case, a suspend could be
> quite harmful.  It would be nice if the userland process could say
> "don't suspend me now, or bad things will happen."
> 
> Solaris has a facility for this called "RCM", whereby userland processes
> can register scripts that get called which can refuse a request to suspend.

I think most of the "policy" should be handled in userland (powerd(8)),
so it this would be relatively easy to handle.

	-- Jachym