Subject: Re: power management
To: Jachym Holecek <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 06/23/2006 15:35:45
Jachym Holecek wrote:
> # 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"?
That won't work, because frankly, sometimes it requires administrator
intervention. Like stopping some critical process -- burning a DVD for
>> 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.
> -- Jachym
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191