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
example.
>
>> 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.
>
Okay.
-- Garrett
> -- Jachym
>
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191