> From: "Theo de Raadt" <dera...@openbsd.org>
> Date: Sat, 16 May 2020 11:34:22 -0600
> 
> Paul Irofti <p...@irofti.net> wrote:
> 
> >     - the clock quality issue was brought back; afaics the current
> >       diff does exactly what the syscall is doing and the
> >       information is updated inside every tc_windup() which makes this
> >       almost an exact replica of the syscall for the clocks in libc;
> >       for the other clocks we go to the syscall and everything is
> >       the same as before
> > 
> > I thought that is what Scott said about the last bit as well. If I
> > missunderstood and clock quality is lost somewhere, I would apprecaite
> > someone with better technical understanding point out the exact issues
> > in the code. Perhaps again Scott?

Let's take CLOCK_MONOTONIC as an example.  The clock_gettime() system
call ends up calling nanouptime(9).  This is the function that returns
a precise result (as opposed to getnanotime(9) which implements
returns the less precise result).

If you look at the implementation of nanouptime(9) you see it calls
binuptime(9).  Inside the loop it has:

    bintimeaddfrac(bt, th->th_scale * tc_delta(th), bt);

This is the bit that actually accesses the hardware to calculate the
precise result adding the elapsed time since the last time the
timehands were updated (when tc_windup() was called).

It is this bit that has to reproduced in userland.

> Let me make it clear this is very important.  Changing this structure
> later will be very painful ABI break.  The high-resolution issue brought
> up by kettenis MUST be considered in the first commit.  There is no point
> commiting drafts of this which simply result in painful ABI breaks in the
> short term.  Meaning, this must not be rushed.

See my proposal in the other mail I sent.

Reply via email to