>
> Ulrich Windl writes:
>
> > I began to convert kernel/time.c to nanoseconds (i.e. xtime is struct
> > timespec instead of struct timeval) now. There are easy changes and
> > more diffucult ones. The stuff in kernel/time.c should be rather easy.
>
> Time should be an integer, not a struct. It ought to fit into a
> register on a 64-bit machine. If an API needs a struct, let libc
> convert as needed. The kernel should use a fast & simple format.
> (that is, a 64-bit integer type should last past 2038)
>
> Considering formats already in common use, we could count from 1601
> in units of 100 ns. That might seem odd, but 1601 is the last 400-year
> mark on the modern calendar.
I will not do it, but you are invited to do that.
>
> > Basically the old functions should be still there, together with new
> > ones. For example we have an old gettimeoffset() that returns
> > microseconds, but we'll need a new one that return nanoseconds.
>
> Call it linux_time_value() just to remind everyone that the
> standard API is implemented in libc.
I also don't want to reinvent the C library.
>
> > Is anybody interested in helping me or testing this very experimental
> > stuff soon? (Together with other changes made for the NTPv4 clock
> > model, binary compatibility with old executables had to be broken:
> > especially adjtime() and ADJ_OFFSET_SINGLESHOT occupy a different bit
> > position now, causing the old adjtime() to be a no-op. I took the
> > chance to cleanup the whole mess.)
>
> Do you _really_ need to kill the old executables? Couldn't you just
> emulate the old system calls?
ADJ_OFFSET_SINGLESHOT is 0x8001 (or something around). It conflicts
with two bit definitions from the NTP interface, namely MOD_OFFSET
and MOD_CLK<something>. As no application program should use adjtimex
directly, it should only be a problem of an updated C library (But as
these updates seem far behind all the time, people simply use the
kernel interface).
At least in the first round I won't have backwards-compatibility. If
I can do it in a second round without re-introducing terrible code, I
might try it.
Regards,
Ulrich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/