In message <Pine.NEB.4.44.0301211258120.16617-100000@lothlorien.starwolf.com>,
Greywolf writes:

>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:
>[JS:
>[JS: Cleaning up the in-kernel interfaces is a Good Thing, but we should
>[JS: provide nanosecond resolution internally (in the kernel) from the
>[JS: get-go.
>
>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,
>now. 

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.