[coyotos-dev] Sleep, wakeup, and persistence

[Valerio Bellizzomi]

On 14/09/2007, at 20.49, Sam Mason wrote:

>On Fri, Sep 14, 2007 at 02:03:51PM -0400, Jonathan S. Shapiro wrote:
>> I want to document a discussion JWA and I had yesterday. This solution
>> is probably well known; it just wasn't well known to us.
>
>Our last discussion of time[1] had the kernel stripped of almost all
>time related functionality.  Is that still the intention, or have things
>changed?
>
>If that is still the case then this is how I see it.
>
>> A process wants to sleep until time X. That is easy if the system keeps
>> running until then, but if the system re-starts what happens?
>> 
>> There are two concerns here:
>> 
>>   1. The underlying system may not have a monotonically increasing
>>      clock. Many embedded systems do not.
>
>What sort of things would these devices have to wait for?  I'd assume
>that if they don't have any sort of real time clock, they wouldn't want
>to wait until some specific real time---at least not until somehow
>determining what the real time is.  They're probably only interested in
>sleeping for short amounts of time to keep timeouts and such working.
>If that's the case then knowing the real time doesn't matter at all.
>
>There seem to be two use cases to me; that of sleeping for a short
>amount of time, and that of sleeping until we reach some specific real
>time.  Why not put the first in the kernel, and leave the second up to
>userspace to implement.


I think I bear with Sam for a fairly fundamental reason: real time can be
measured in a variety of ways, and I don't want the kernel to be stuck
with one particular measure.

>
>That way, our embedded system can have the time punched into its
>panel/ask some network server and eventually get an answer.  In the
>meantime, it can be relying on the kernel for short timeouts.  A PC
>would be able to get a good estimate of the real time from its clock
>quickly so will be able to start servicing "real time" alarms (for lack
>of a better word) quickly.


There is a problem with that, I have a P4 mainboard that gains seconds
faster than NTP clock.
The mainboard clock counts faster than real time, so when NTP time is
updated, the real time actually goes backwards.


>
>> To deal with these cases, I believe that the semantics of sleep() must
>> be as follows:
>> 
>>   1. It means "wake me up as soon as possible after time X"
>>   2. The caller needs to be able to specify whether a system
>>      restart should terminate the sleep.
>>   3. The result needs to indicate whether an intervening restart
>>      occurred.
>> 
>> This fully exposes the restart mechanism to anybody who can perform a
>> sleep operation, but I simply do not see any way to rationalize sleep
>> without this. A checkpointing system is capable of a restricted form of
>> "time travel", so a notion of time travel epoch would appear to be
>> intrinsic.
>
>That seems like a reasonable set of semantics for the kernel's sleep.
>I'm not sure what you'd do for the "real time" alarm service.
>
>
>  Sam
>
> [1]
http://www.coyotos.org/pipermail/coyotos-dev/2007-January/000728.html
>_______________________________________________
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
>http://www.coyotos.org/mailman/listinfo/coyotos-dev