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

[George Anzinger <george@mvista.com>]

Pavel Machek wrote:
> Hi!
> 
> 
>>>You are not asking userspace whether to reboot or not, and you should
>>>not ask them about suspend, either.
>>
>>OK, so how should the system behave when a real-time-like process is
>>running? I talked about the CD burning example. Should the kernel simply
>>ignore the process and suspend?
> 
> 
> Yes.
> 
> 
>>>>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.
>>
>>Does "gettimeofday()" have into account the effect of adjusting the time
>>twice a year, once to make time roll forward one hour and another one to
>>roll it back?
> 
> 
> Not sure how it is supposed to work, but here I just have ntpd
> step-setting by one hour...

It is really a time zone change....

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml