Re: [pm] fix time after suspend-to-*

[Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>]

On Tue, 2003-10-28 at 10:32, Pavel Machek wrote:

> > Many userspace applications are not prepared for suspension, like
> > Evolution. When suspending the machine for a long time, all IMAP
> > sessions are broken as their counterpart TCP sockets timeout. While
> > resuming, Evolution is unable to handle this condition and simply
> > informs the network connection has been dropped.
> > 
> > What about sending the SIGPWR signal to all userspace processes before
> > suspending so applications like Evolution can be improved to handle this
> > signal, drop their IMAP connections and then, when resuming, reestablish
> > them?
> 
> Not sure... We do not want applications to know. Certainly we can't
> send a signal; SIGPWR already has some meaning and it would be bad to
> override it.

OK, maybe using SIGPWR is not a good idea, but some userspace
applications need to know when the system is going to sleep. Even more,
userspace apps should be able to tell the kernel whether suspending the
system at a given moment is a good idea or not.

Examples:

1. Network connections must be reestablished. A userspace program can't
try to automatically reestablish a broken TCP connection for no apparent
reason. A broken TCP connection could be the cause of an overloaded or
broken server/service. If we do not inform userspace processes that the
system is going to sleep (or that the system has been brought up from
standby), they will blindly try to restore TCP connections back, even
when the remote server is broken, generating a lot of unnecesary
traffic.

2. Sound: I've been unable to suspend via APM with the Yamaha YMFPCI
driver loaded. I need to unload it, but I can't unload it if there is
some app using the sound driver. Before going to sleep, sound-aware apps
could be informed that the system is being put to sleep so that they
stop playing sound gracefully. Thus, the sound driver could be unloaded.

3. CD/DVD burners: Some userspace apps should be able to try to avoid
suspending the system. Imagine what could happen if average joe user
tries to suspend while burning a CD. The CD recording app should be able
to notify the kernel that a real-time sensitive operation is being taken
place. A policy-based decision system could take the responsibility to
prevent the system from entering suspension or ignore the userspace
application and force the suspend, for example, to prevent losing data
when a laptop is really, really low on batteries.

Don't know if I'm able to convince you ;-)