Messages in this thread | | | Date | Tue, 27 Jul 1999 18:32:43 +0200 (CEST) | From | Robert de Vries <> | Subject | Re: PATCH: POSIX 1003.1b timer minor fixes |
| |
On Tue, 27 Jul 1999, Jakub Jelinek wrote:
> > On the other side I wonder why are sys_clock_* in the kernel unless higher > than microsecond resolution is implemented. It seems to me like they really > don't do any job which could not be done in glibc, and do > not give even any performance advantages over it. >
Ah, but the implementation I have submitted is the bare bones super minimum POSIX implementation. Now everybody can add her own special clock/timer to the kernel. For instance if I would want to add an IRIG-B clock I just needed to write a device driver for the card and hook it into the system call infrastructure I have provided. It is not necessary to provide timer and clock functionality for each CLOCK_<type>. Some clocks cannot generate interrupts in order to be usable as a timer, but can only be used as a clock. In that case you just implement the clock_* functions.
Secondly I remember that not too long ago I heard someone ask for greater precision for the clock function gettimeofday. So someone is interested in nanosecond precision. So there it is, go ahead, and implement gettimeofday as clock_gettime(CLOCK_REALTIME, :-).
Thirdly, on SGI IRIX 6.5 for some clocks (e.g. CLOCK_CYCLECNTR), the function clock_gettime() maps some hardware registers to user space and reads them, instead of doing an expensive system call.
On an i386 you could maybe access the Time Stamp Counter from user space and offer a user space implementation which just returns the value from the TSC (after converting it to struct timespec). If SGI gets away with it so could the Linux community. For superfast interval timing this would be excellent.
Robert
- 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/
| |