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