If the hardware provides a periodic clock or timer, it will be used to drive timing-related features of the system. Many CPU architectures now have built in timer registers that can provide a periodic interrupt. This should be used to drive these features where possible. Otherwise an external timer/clock chip must be used.
We draw a distinction between Counters, Clocks, Alarms and Timers. A Counter maintains a monotonically increasing counter that is driven by some source of ticks. A Clock is a counter driven by a regular source of ticks (i.e. it counts time). Clocks have a resolution associated with them. A default system Clock is driven by the periodic interrupt described above, and tracks real-time. Other interrupt sources may drive other Counters that may or may not track real-time at different resolutions. Some Counters may be driven by aperiodic events and thus have no relation to real-time at all.
An Alarm is attached to a Counter and provides a mechanism for generating single-shot or periodic events based on the counter"s value. A Timer is simply an Alarm that is attached to a Clock.
The system (including the kernel) represents time in units of ticks. These are clock-specific time units and are usually the period of the timer interrupt, or a multiple thereof. Conversion of ticks into conventional time and date units should occur only when required via library functions. Equivalence between Clock time and real-time can be made with an RTC (real-time clock), NTP (network time protocol) or user input.
The representation of the current tick count needs to be 64 bit. This requires either compiler support for 64 bit integers, or assembly code. Even at the extreme of a 1 ns tick (ticks will typically be >1ms), this gives a 584 year rollover period.
The Clock API and configuration options that affect clock, counter and alarm behavior are described in detail in the section called Counters, clocks and alarms in Chapter 5.