lkml.org 
[lkml]   [1999]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans