Subject: Re: power management
To: Jachym Holecek <>
From: Garrett D'Amore <>
List: tech-kern
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
>> later."
> 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
>> 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.


    -- Garrett
> 	-- Jachym

Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134  Fax: 951 325-2191