> Let me illustrate with a small example of how I see the implementation in
> the C library of clock_gettime().
...
> int clock_gettime(clockid_t which_clock, struct timespec *current_time)
> {
> switch (which_clock) {
> case CLOCK_TSC:
> return tsc_gettime(current_time);
> default:
> return sys_clock_gettime(which_clock,
> current_time);
> }
> }
I suppose nobody wants to hear this right now, but...
It appears that you expect the kernel to accept a pointer to a timespec
struct. Why? You can't sanely work with data in that format.
The kernel is supposed to be light, fast, simple, etc.
One generally puts crufty API junk in the C library.
With the cruft in the kernel, we get bloat for everyone
and not even a way to bypass it.
Plain 64-bit nanoseconds are nice and simple. Alpha and sparc64 systems
can do very fast operations on such a data type, and intel junk won't
do too badly with recent compilers.
Plain 64-bit values at hardware resolution are also OK. They let
you push some multiplication and/or division out into userspace,
but you pay a bit in other places.
Simple fundamental features are often better. The kernel needs to
support POSIX, Java, and various emulators. Aside from a few missing
bits, clone() is an example of a good system call. You can support
many different kinds of threads on top of one clean system call.
Time functions ought to be as clean.
Well, I hope that didn't annoy anyone too much. We are still in
early 2.3.xx, so now is a good time for change.
-
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/