Re: Bug fix for PR 26470 for review

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, May 26, 2008 at 12:00:44PM -0700, Dennis Ferguson wrote:
> Well, if we're reduced to quoting standardese, how about this one
> from the SUS for clock_settime():

OK, that makes more sense.

> I don't know what behaviour you are talking about.  time and uptime
> are (or should be) the same time from the same clock; they differ only by
> a near-constant "boottime" which is maintained so that
>
>     time = uptime + boottime

Yes.

> I don't have a good handle on what timers should do when the system isn't
> running (nor does the SUS, for that matter), so if you don't like what
> uptime does when the system is suspended feel free to fix that (maybe
> you can set uptime = time - boottime when you wake up).  I can tell you
> for sure, however, that what uptime does when the system is running is
> exactly, precisely what relative time functions need (if it isn't it
> should be fixed).  That is its purpose, its only purpose.

At the very least you want the system to behave as it continued to run.
E.g. nanosleep should timeout, so that DHCP leases are reacquired
etc. Doing that correctly involved changes to some kernel interfaces and
testing, which is somewhat outside the scope of this patch. I will go on
with the patch and look at switching it to use uptime in a second step.

>> Given the guarantied reslution of 1/HZ only the effect of phase
>> adjustments should be irrelevant.
>
> Umm, we're not talking small differences here.  Try the attached program.

Sorry, wrong wording. I meant drift correction.

Joerg