From: "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> To: linux-kernel@vger.rutgers.edu Date: Tue, 16 Feb 1999 09:28:12 +0100 Subject: RFD: nanoseconds in the kernel, POSIX.4, cleanups Hello, 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/