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

[Pavel Machek <pavel@suse.cz>]

Hi!

> > 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.

You are not asking userspace whether to reboot or not, and you should
not ask them about suspend, either.

> 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.

gettimeofday(), if I slept for too long, oops, something strange
happened (maybe there was heavy io load and I was swapped out? or
suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.

> 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.

Fix the driver.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]