Subject: Re: power management
To: Garrett D'Amore <email@example.com>
From: Jachym Holecek <firstname.lastname@example.org>
Date: 06/24/2006 00:14:56
# 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
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
> 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.