[ntp:questions] Re: Monitoring the leap second tonight

Richard B. Gilbert rgilbert88 at comcast.net
Sun Jan 1 16:33:48 UTC 2006

Markus Kuhn wrote:

>Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen <hjj at wheel.dk> writes:
>|> >>   http://www.cl.cam.ac.uk/~mgk25/time/leap/timelog.c
>|> >>
>|> > But what about non X86 arch?
>|> Some hack needed on Solaris sparc:
>|> bash-2.03$ gcc timelog.c
>|> timelog.c: In function `read_tsc':
>|> timelog.c:44: unknown register name `edx' in `asm'
>|> timelog.c:44: unknown register name `eax' in `asm'
>You obviously need to undef HAVE_PENTIUM_TSC if you don't have one.
>Can't think of an easy portable compile-time test for that one.
>|> timelog.c: In function `main':
>|> timelog.c:113: `CLOCK_MONOTONIC' undeclared (first use in this function)
>|> timelog.c:113: (Each undeclared identifier is reported only once
>|> timelog.c:113: for each function it appears in.)
>|> timelog.c:114: `CLOCK_PROCESS_CPUTIME_ID' undeclared (first use in this function)
>|> timelog.c:115: `CLOCK_THREAD_CPUTIME_ID' undeclared (first use in this function)
>OK, fixed. I've added lots of #ifdef's using the POSIX macros
>Even this little test routine has now ended up as the sort of #ifdef
>spaghetti junction that makes every POSIX committee proud ... :-(
>In principle, clock_gettime() is a far more sensible API
>function than gettimeofday(). But the sad state of support
>of clock_gettime() does not yet make it a very attractive
>substitute for the ubiquitously available gettimeofday().
>I see some homework for glibc and kernel developers here!
>Actually, I see no reason whatsoever for why clock_gettime() should be
>implemented in the kernel as a system call. All the kernel needs
>to provide is to map into user space the conversion parameters
>between the hardware clock and the various different POSIX clock
>types. It also must grant user space direct read access to the clock
>hardware. Then, API calls for querying the time will no longer
>add the entire kernel context switch overhead as noise to their
>measurements. The implementation of clock_gettime() and gettimeofday()
>should be as fast and predictable as possible; both of these
>requirements speak strongly against involving the kernel directly.
OK!   The current version builds and runs on Solaris 8/SPARC.

Thank you!!

More information about the questions mailing list