lkml.org 
[lkml]   [1999]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRFD: nanoseconds in the kernel, POSIX.4, cleanups

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.

> 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.

> 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?

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.113 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site