Messages in this thread | | | Date | Tue, 28 Oct 2003 18:28:18 +0100 | From | Pavel Machek <> | Subject | Re: [pm] fix time after suspend-to-* |
| |
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?] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |