Subject: Re: machine-independent cycle counter based microtime()
To: Greywolf <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/21/2003 13:22:24
In message <Pine.NEB.email@example.com>,
>On Tue, 21 Jan 2003, Jonathan Stone wrote:
>[JS: >...why not just call it cycletime()? That should get us into the next
>[JS: >century or so.
>[JS: Cleaning up the in-kernel interfaces is a Good Thing, but we should
>[JS: provide nanosecond resolution internally (in the kernel) from the
>You didn't read (or at least you did not quote) the second part of my
>suggestion which was that "micro" perhaps ought to be viewed as meaning
>"small", i.e., "subsecond" in the context of time. So it's nanoseconds,
Balderdash. Our microtime is, in fact,
microtime(struct timeval *tv)
not some blithering hypothetical abstract `high-resolution'' interface.
I'm suggesting that, if we are cleaning up high-resolution timekeeping,
that we start implementing
void nanotime(struct timespec *)
[or perhaps even a struct-returning function, since ANSI C has
supported those for years]. Until all the kernel is reworked to use
timespecs, we will need to provide microtime(). Wrappers to either
implement microtime() as nanotime() [or vice-versa] using an
arch/port-specific feature-test, is an simple exercise for the reader.
An MI interface for high-res counters, with a smaller impedance
msmatch to the interface in Dave Mill's ``nanokernel' than the rnd
macros, would still be a Very Nice Thing, but that is a different topic.