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.
The architecture-specific kernel/time.c is more tricky, especially as
I don't know much about all these.
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.
There are two solutions: 1) Keep the old functions, and derive the
new ones by simply scaling-up the old stuff. 2) Make new functions in
addition to the old ones 3) Make new fuctions for nanoseconds, and
map the old ones to the new ones.
Of course I'd vote for "3)".
A rather unrelated issue is that of naming: Having in mind the
ability to support more of POSIX.4, we could have clock_gettime() to
get the time in nanoseconds, and clock_settime() to set the time.
clock_getres() that returns the resolution seems tricky if done
correctly. (Or should I simply assume "1ns"?)
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.)
BTW: Do you think external modules should need access to all the time
variables? These were declared in <linux/timex.h> before, but they
are no longer, because there were too many changes. Despite of that I
think that "clients" should use the official interface defined by
functions.
I'm also considering why the fuction to set the time is currently in
the architecture-specific arch-*/kernel/time.c. It only seems to need
the fast timeoffset, but it could be exported from there. I'll have
to check when I'm that far.
Opinions, please!
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/