Messages in this thread | | | Date | Thu, 29 Jul 1999 03:47:09 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: PATCH: POSIX 1003.1b timer minor fixes |
| |
Robert de Vries writes:
> 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/
| |