Hi,

> How much does adjtime() slew the clock by, default?  .1%?  Then if you
> sleep for a thousand ticks - ten seconds on most machines - you can be
> as much as a whole tick out thanks to adjtime.  I know _I_'d certainly
> be annoyed if I requested a timer tick once a second and then,
> according to gettimeofday(), actually got it every 1.001 second,
> thereby slowly drifting with respect to second boundaries.

Well, then I gues you have to stop using any non real-time operating
system at all. If sleeping for an amount of time means, that the process
will sleep at leat that long (Note that I mean sleeping for relativ
time, not an absolute one). It doesn't guarantee you, that your process
will be run, after this time has exceeded. The process might have been swapped
out and needs to be swapped in again, or there are simply other processes
available with higher priorities. Thus you shouldn't (actually can't)
rely on your process being awakened exactly after one second. AFAIK, semantics
has always been sleeping at least as long (or until a signal occurs).

> That would help too...but there are also programs (cron, for example)
> that want to take positive action when the time of day steps, not just
> be awakened on a time-of-day basis - cron, for example, needs this so
> that if the timewarp is backwards, it runs jobs twice correctly.  (If I
> set the time back by a day, I don't want cron to lock up solid for a
> day, waiting until gettimeofday() catches up with when cron thought the
> next cron job was scheduled for, and therefore slept until.)  Of
> course, cron couldn't _just_ use ITIMER_ABSOLUTE, since it also has to
> watch for new crontabs being installed.

For the stuff in the kernel, an ITIMER_RELATIVE would be enough.
This could be also used by processes that just want to sleep for 
a certain amount of time and don't care about changes of the absolute 
time. IMHO adjtime() should just be ignored in these cases.

For applications like cron you mention above, ITIMER_ABSOLUTE could
be used. If the absolute time is set to a different value, then
processes sleeping on ITIMER_ABSOLUTE will be woken up and have
the number of (u)seconds actually slept returned. Then leave it up to
the processes to deal with the fact, that the time might have changed
in the meantime. These processes have to check if they have been interrupted
by a signal anyways. I don't see any reasonable way to integrate support
for cron into the kernel, as might be one of the few tools that actually
do sth. regulary on a system and have a special reaction towards changes
of the real time.

  Guenther