Peter Seebach wrote:
> In message <20060622174330.GX11554@multics.mit.edu>, "Charles M. Hannum" writes
> :
>
>> There's an important item you missed. Drivers need to supply positive
>> acknowledgement before a suspend happens. If there are drivers
>> incapable of suspending properly, the system should not suspend -- you
>> should never see "the machine woke up, but XXX doesn't work any more".
>>
>
> 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.
I have lots of experience with suspend/resume in Solaris-land. (Even
the very high end platforms have a need to suspend when doing dynamic
reconfiguration, e.g. to remove system boards that have kernel memory on
them, you need to suspend while the kernel shuffles memory around.)
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."
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.
-- Garrett
> -s
>
--
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