Bye bye xntpd.

3 files changed, 0 insertions, 748 deletions

diff --git a/usr.sbin/xntpd/kernel/README.kern b/usr.sbin/xntpd/kernel/README.kern
deleted file mode 100644
index 64ba9c5..0000000
--- a/usr.sbin/xntpd/kernel/README.kern
+++ /dev/null
@@ -1,596 +0,0 @@
-Precision Time and Frequency Synchronization Using Modified Kernels
-
-1. Introduction
-
-This memo describes replacements for certain SunOS and Ultrix kernel
-routines that manage the system clock and timer functions. They provide
-improved accuracy and stability through the use of a disciplined clock
-interface for use with the Network Time Protocol (NTP) or similar time-
-synchronization protocol. In addition, for certain models of the
-DECstation 5000 product line, the new routines provide improved
-precision to +-1 microsecond (us) (SunOS 4.1.1 already does provide
-precision to +-1 us). The current public NTP distribution cooperates
-with these kernel routines to provide synchronization in principle to
-within a microsecond, but in practice this is limited by the short-term
-stability of the oscillator that drives the timer interrupt.
-
-This memo describes the principles behind the design and operation of
-the software. There are two versions of the software, one that operates
-with the SunOS 4.1.1 kernel and the other that operates with the Ultrix
-4.2a kernel (and probably the 4.3 kernel, although this has not been
-tested). A detailed description of the variables and algorithms is given
-in the hope that similar improvements can be incorporated in Unix
-kernels for other machines. The software itself is not included in this
-memo, since it involves licensed code. Detailed instructions on where to
-obtain it for either SunOS or Ultrix will be given separately.
-
-The principle function added to the SunOS and Ultrix kernels is to
-change the way the system clock is controlled, in order to provide
-precision time and frequency adjustments. Another function utilizes an
-undocumented counter in the DECstation hardware to provide precise time
-to the microsecond. This function can be used only with the DECstation
-5000/240 and possibly others that use the same input/output chipset.
-
-2. Design Principles
-
-In order to understand how these routines work, it is useful to consider
-how most Unix systems maintain the system clock. In the original design
-a hardware timer interrupts the kernel at some fixed rate, such as 100
-Hz in the SunOS kernel and 256 Hz in the Ultrix kernel. Since 256 does
-not evenly divide the second in microseconds, the kernel inserts 64 us
-once each second so that the system clock stays in step with real time.
-The time returned by the gettimeofday() routine is thus characterized by
-255 advances of 3906 us plus one of 3970 us.
-
-Also in the original design it is possible to slew the system clock to a
-new offset using the adjtime() system call. To do this the clock
-frequency is changed by adding or subtracting a fixed amount (tickadj)
-at each timer interrupt (tick) for a calculated number of ticks. Since
-this calculation involves dividing the requested offset by tickadj, it
-is possible to slew to a new offset with a precision only of tickadj,
-which is usually in the neighborhood of 5 us, but sometimes much higher.
-
-In order to maintain the system clock within specified bounds with this
-scheme, it is necessary to call adjtime() on a regular basis. For
-instance, let the bound be set at 100 us, which is a reasonable value
-for NTP-synchronized hosts on a local network, and let the onboard
-oscillator tolerance be 100 ppm, which is a reasonably conservative
-assumption. This requires that adjtime() be called at intervals not
-exceeding 1 second (s), which is in fact what the unmodified NTP
-software daemon does.
-
-In the modified kernel routines this scheme is replaced by another that
-extends the low-order bits of the system clock to provide very precise
-clock adjustments. At each timer interrupt a precisely calibrated time
-adjustment is added to the composite time value and overflows handled as
-required. The quantity to add is computed from the adjtime() call and,
-in addition a frequency adjustment, which is automatically calculated
-from previous time adjustments. This implementation operates as an
-adaptive-parameter, first-order, type-II, phase-lock loop (PLL), which
-in principle provides precision control of the system clock phase to
-within +-1 us and frequency to within +-5 nanoseconds (ns) per day.
-
-This PLL model is identical to the one implemented in NTP, except that
-in NTP the software daemon has to simulate the PLL using only the
-original adjtime() system call. The daemon is considerably complicated
-by the need to parcel time adjustments at frequent intervals in order to
-maintain the accuracy to specified bounds. The kernel routines do this
-directly, allowing vast gobs of ugly daemon code to be avoided at the
-expense of only a small amount of new code in the kernel. In fact, the
-amount of code added to the kernel for the new scheme is about the
-amount removed for the old scheme. The new adjtime() routine needs to be
-called only as each new time update is determined, which in NTP occurs
-at intervals of from 64 s to 1024 s. In addition, doing the frequency
-correction in the kernel means that the system time runs true even if
-the daemon were to cease operation or the network paths to the primary
-reference source fail.
-
-Note that the degree to which the adjtime() adjustment can be made is
-limited to a specific maximum value, presently +-128 milliseconds (ms),
-in order to achieve microsecond resolution. It is the intent in the
-design that settimeofday() be used for changes in system time greater
-than +-128 ms. It has been the Internet experience that the need to
-change the system time in increments greater than +-128 milliseconds is
-extremely rare and is usually associated with a hardware or software
-malfunction. Nevertheless, the limit applies to each adjtime() call and
-it is possible, but not recommended, that this routine is called at
-intervals smaller than 64 seconds, which is the NTP lower limit.
-
-For the most accurate and stable operation, adjtime() should be called
-at specified intervals; however, the PLL is quite forgiving and neither
-moderate loss of updates nor variations in the length of the interval is
-serious. The current engineering parameters have been optimized for
-intervals not greater than about 64 s. For larger intervals the PLL time
-constant can be adjusted to optimize the dynamic response up to
-intervals of 1024 s. Normally, this is automatically done by NTP. In any
-case, if updates are suspended, the PLL coasts at the frequency last
-determinated, which usually results in errors increasing only to a few
-tens of milliseconds over a day.
-
-The new code needs to know the initial frequency offset and time
-constant for the PLL, and the daemon needs to know the current frequency
-offset computed by the kernel for monitoring purposes. This is provided
-by a small change in the second argument of the kernel adjtime() calling
-sequence, which is documented later in this memo. Ordinarily, only the
-daemon will call the adjtime() routine, so the modified calling sequence
-is easily accommodated. Other than this change, the operation of
-adjtime() is transparent to the original.
-
-In the DECstation 5000/240 and possibly other models there happens to be
-an undocumented hardware register that counts system bus cycles at a
-rate of 25 MHz. The new kernel routines test for the CPU type and, in
-the case of the '240, use this register to interpolate system time
-between hardware timer interrupts. This results in a precision of +-1 us
-for all time values obtained via the gettimeofday() system call. This
-routine calls the kernel routine microtime(), which returns the actual
-interpolated value, but does not change the kernel time variable.
-Therefore, other kernel routines that access the kernel time variable
-directly and do not call either gettimeofday() or microtime() will
-continue their present behavior.
-
-The new kernel routines include provisions for error statistics (maximum
-error and estimated error), leap seconds and system clock status. These
-are intended to support applications that need such things; however,
-there are no applications other than the time-synchronization daemon
-itself that presently use them. At issue is the manner in which these
-data can be provided to application clients, such as new system calls
-and data interfaces. While a proposed interface is described later in
-this memo, it has not yet been implemented. This is an area for further
-study.
-
-While any time-synchronization daemon can in principle be modified to
-use the new code, the most likely will be users of the xntp3
-distribution of NTP. The code in the xntp3 distribution determines
-whether the new kernel code is in use and automatically reconfigures as
-required. When the new code is in use, the daemon reads the frequency
-offset from a file and provides it and the initial time constant via
-adjtime(). In subsequent calls to adjtime(), only the time adjustment
-and time constant are affected. The daemon reads the frequency from the
-kernel (returned as the second argument of adjtime()) at intervals of
-one hour and writes it to the file.
-
-3. Technical Description
-
-Following is a technical description of how the new scheme works in
-terms of the variables and algorithms involved. These components are
-discussed as a distinct entity and do not involve coding details
-specific to the Ultrix kernel. The algorithms involve only minor changes
-to the system clock and interval timer routines, but do not in
-themselves provide a conduit for application programs to learn the
-system clock status or statistics of the time-synchronization process.
-In a later section a number of new system calls are proposed to do this,
-along with an interface specification.
-
-The new scheme works like the companion simulator called kern.c and
-included in this directory. This stand-alone simulator includes code
-fragments identical to those in the modified kernel routines and
-operates in the same way. The system clock is implemented in the kernel
-using a set of variables and algorithms defined below and in the
-simulator. The algorithms are driven by explicit calls from the
-synchronization protocol as each time update is computed. The clock is
-read and set using the gettimeofday() and settimeofday() system calls,
-which operate in the same way as the originals, but return a status word
-describing the state of the system clock.
-
-Once the system clock has been set, the adjtime() system call is used to
-provide periodic updates including the time offset and possibly
-frequency offset and time constant. With NTP this occurs at intervals of
-from 64 s to 1024 s, deending on the time constant value. The kernel
-implements an adaptive-parameter, first-order, type-II, phase-lock loop
-(PLL) in order to integrate this offset into the phase and frequency of
-the system clock. The kernel keeps track of the time of the last update
-and adjusts the maximum error to grow by an amount equal to the
-oscillator frequency tolerance times the elapsed time since the last
-update.
-
-Occasionally, it is necessary to adjust the PLL parameters in response
-to environmental conditions, such as leap-second warning and oscillator
-stability observations. While the interface to do this has not yet been
-implemented, proposals to to that are included in a later section. A
-system call (setloop()) is used on such occasions to communicate these
-data. In addition, a system call (getloop())) is used to extract these
-data from the kernel for monitoring purposes.
-
-All programs utilize the system clock status variable time_status, which
-records whether the clock is synchronized, waiting for a leap second,
-etc. The value of this variable is returned by each system call. It can
-be set explicitly by the setloop() system call and implicitly by the
-settimeofday() system call and in the timer-interrupt routine. Values
-presently defined in the header file timex.h are as follows:
-
-int time_status = TIME_BAD;     /* clock synchronization status */
-
-#define TIME_UNS 0      /* unspecified or unknown */
-#define TIME_OK 1       /* operation succeeded */
-#define TIME_INS 1      /* insert leap second at end of current day */
-#define TIME_DEL 2      /* delete leap second at end of current day */
-#define TIME_OOP 3      /* leap second in progress */
-#define TIME_BAD 4      /* system clock is not synchronized */
-#define TIME_ADR -1     /* operation failed: invalid address */
-#define TIME_VAL -2     /* operation failed: invalid argument */
-#define TIME_PRV -3     /* operation failed: priviledged operation */
-
-In case of a negative result code, the operation has failed; however,
-some variables may have been modified before the error was detected.
-Note that the new system calls never return a value of zero, so it is
-possible to determine whether the old routines or the new ones are in
-use. The syntax of the modified adjtime() is as follows:
-
-/*
- * adjtime - adjuts system time
- */
-#include <sys/timex.h>
-
-int gettimexofday(tp, fiddle)
-
-struct timeval *tp;     /* system time adjustment*/
-struct timeval *fiddle; /* sneak path */
-
-On entry the "timeval" sneak path is coded:
-
-struct timeval {
-        long tv_sec = time_constant;    /* time constant */
-        long tv_usec = time_freq;       /* new frequency offset */
-}
-
-However, the sneak is ignored if fiddle is the null pointer and the new
-frequency offset is ignored if zero.
-
-The value returned on exit is the system clock status defined above. The
-"timeval" sneak path is modified as follows:
-
-struct timeval {
-        long tv_sec = time_precision;   /* system clock precision */
-        long tv_usec = time_freq;       /* current frequency offset */
-}
-
-3.1. Kernel Variables
-
-The following variables are used by the new code:
-
-long time_offset = 0;           /* time adjustment (us) */
-
-This variable is used by the PLL to adjust the system time in small
-increments. It is scaled by (1 << SHIFT_UPDATE) in binary microseconds.
-The maximum value that can be represented is about +-130 ms and the
-minimum value or precision is about one nanosecond.
-
-long time_constant = SHIFT_TAU; /* pll time constant */
-
-This variable determines the bandwidth or "stiffness" of the PLL. It is
-used as a shift, with the effective value in positive powers of two. The
-optimum value for this variable is equal to 1/64 times the update
-interval. The default value SHIFT_TAU (0) corresponds to a PLL time
-constant of about one hour or an update interval of about one minute,
-which is appropriate for typical uncompensated quartz oscillators used
-in most computing equipment. Values larger than four are not useful,
-unless the local clock timebase is derived from a precision oscillator.
-
-long time_tolerance = MAXFREQ;  /* frequency tolerance (ppm) */
-
-This variable represents the maximum frequency error or tolerance of the
-particular platform and is a property of the architecture. It is
-expressed as a positive number greater than zero in parts-per-million
-(ppm). The default MAXFREQ (100) is appropriate for conventional
-workstations.
-
-long time_precision = 1000000 / HZ; /* clock precision (us) */
-
-This variable represents the maximum error in reading the system clock.
-It is expressed as a positive number greater than zero in microseconds
-and is usually based on the number of microseconds between timer
-interrupts, in the case of the Ultrix kernel, 3906. However, in cases
-where the time can be interpolated between timer interrupts with
-microsecond resolution, the precision is specified as 1. This variable
-is computed by the kernel for use by the time-synchronization daemon,
-but is otherwise not used by the kernel.
-
-struct timeval time_maxerror;   /* maximum error */
-
-This variable represents the maximum error, expressed as a Unix timeval,
-of the system clock. For NTP, it is computed as the synchronization
-distance, which is equal to one-half the root delay plus the root
-dispersion. It is increased by a small amount (time_tolerance) each
-second to reflect the clock frequency tolerance. This variable is
-computed by the time-synchronization daemon and the kernel for use by
-the application program, but is otherwise not used by the kernel.
-
-struct timeval time_esterror;   /* estimated error */
-
-This variable represents the best estimate of the actual error,
-expressed as a Unix timeval, of the system clock based on its past
-behavior, together with observations of multiple clocks within the peer
-group. This variable is computed by the time-synchronization daemon for
-use by the application program, but is otherwise not used by the kernel.
-
-The PLL itself is controlled by the following variables:
-
-long time_phase = 0;            /* phase offset (scaled us) */
-long time_freq = 0;             /* frequency offset (scaled ppm) */long
-time_adj = 0;                   /* tick adjust (scaled 1 / HZ) */
-
-These variables control the phase increment and the frequency increment
-of the system clock at each tick of the clock. The time_phase variable
-is scaled by (1 << SHIFT_SCALE) in binary microseconds, giving a minimum
-value (time resolution) of 9.3e-10 us. The time_freq variable is scaled
-by (1 << SHIFT_KF) in parts-per-million (ppm), giving it a maximum value
-of about +-130 ppm and a minimum value (frequency resolution) of 6e-8
-ppm. The time_adj variable is the actual phase increment in scaled
-microseconds to add to time_phase once each tick. It is computed from
-time_phase and time_freq once per second.
-
-long time_reftime = 0;          /* time at last adjustment (s) */
-
-This variable is the second's portion of the system time on the last
-call to adjtime(). It is used to adjust the time_freq variable as the
-time since the last update increases.
-
-The HZ define establishes the timer interrupt frequency, 256 Hz for the
-Ultrix kernel and 100 Hz for the SunOS kernel. The SHIFT_HZ define
-expresses the same value as the nearest power of two in order to avoid
-hardware multiply operations. These are the only parameters that need to
-be changed for different timer interrupt rates.
-
-#define HZ 256                  /* timer interrupt frequency (Hz) */
-#define SHIFT_HZ 8              /* log2(HZ) */
-
-The following defines establish the engineering parameters of the PLL
-model. They are chosen for an initial convergence time of about an hour,
-an overshoot of about seven percent and a final convergence time of
-several hours, depending on initial frequency error.
-
-#define SHIFT_KG 10             /* shift for phase increment */
-#define SHIFT_KF 24             /* shift for frequency increment */
-#define SHIFT_TAU 0             /* default time constant (shift) */
-
-The SHIFT_SCALE define establishes the decimal point on the time_phase
-variable which serves as a an extension to the low-order bits of the
-system clock variable. The SHIFT_UPDATE define establishes the decimal
-point of the phase portion of the adjtime() update. The FINEUSEC define
-represents 1 us in scaled units.
-
-#define SHIFT_SCALE 28          /* shift for scale factor */
-#define SHIFT_UPDATE 14         /* shift for offset scale factor */
-#define FINEUSEC (1 << SHIFT_SCALE) /* 1 us in scaled units */
-
-The FINETUNE define represents the residual, in ppm, to be added to the
-system clock variable in addition to the integral 1-us value given by
-tick. This allows a systematic frequency offset in cases where the timer
-interrupt frequency does not exactly divide the second in microseconds.
-
-#define FINETUNE (1000000 - (1000000 / HZ) * HZ) /* frequency adjustment
-                                 * for non-isochronous HZ (ppm) */
-
-The following four defines establish the performance envelope of the
-PLL, one to bound the maximum phase error, another to bound the maximum
-frequency error and the last two to bound the minimum and maximum time
-between updates. The intent of these bounds is to force the PLL to
-operate within predefined limits in order to conform to the correctness
-models assumed by time-synchronization protocols like NTP and DTSS. An
-excursion which exceeds these bounds is clamped to the bound and
-operation proceeds accordingly. In practice, this can occur only if
-something has failed or is operating out of tolerance, but otherwise the
-PLL continues to operate in a stable mode. Note that the MAXPHASE define
-conforms to the maximum offset allowed in NTP before the system time is
-reset, rather than incrementally adjusted.
-
-#define MAXPHASE 128000         /* max phase error (us) */
-#define MINSEC 64               /* min interval between updates (s) */
-#define MAXFREQ 100             /* max frequency error (ppm) */
-#define MAXSEC 1024             /* max interval between updates (s) */
-
-3.2. Code Segments
-
-The code segments illustrated in the simulator should make clear the
-operations at various points in the code. These segments are not derived
-from any licensed code. The hardupdate() fragment is called by adjtime()
-to update the system clock phase and frequency. This is an
-implementation of an adaptive-parameter, first-order, type-II phase-lock
-loop. Note that the time constant is in units of powers of two, so that
-multiplies can be done by simple shifts. The phase variable is computed
-as the offset multiplied by the time constant. Then, the time since the
-last update is computed and clamped to a maximum (for robustness) and to
-zero if initializing. The offset is multiplied (sorry about the ugly
-multiply) by the result and by the square of the time constant and then
-added to the frequency variable. Finally, the frequency variable is
-clamped not to exceed the tolerance. Note that all shifts are assumed to
-be positive and that a shift of a signed quantity to the right requires
-a litle dance.
-
-With the defines given, the maximum time offset is determined by the
-size in bits of the long type (32) less the SHIFT_UPDATE (14) scale
-factor or 18 bits (signed). The scale factor is chosen so that there is
-no loss of significance in later steps, which may involve a right shift
-up to 14 bits. This results in a maximum offset of about +-130 ms. Since
-the time_constant must be greater than or equal to zero, the maximum
-frequency offset is determined by the SHIFT_KF (24) scale factor, or
-about +-130 ppm. In the addition step the value of offset * mtemp is
-represented in 18 + 10 = 28 bits, which will not overflow a long add.
-There could be a loss of precision due to the right shift of up to eight
-bits, since time_constant is bounded at four. This results in a net
-worst-case frequency error of about 2^-16 us or well down into the
-oscillator phase noise. While the time_offset value is assumed checked
-before entry, the time_phase variable is an accumulator, so is clamped
-to the tolerance on every call. This helps to damp transients before the
-oscillator frequency has been determined, as well as to satisfy the
-correctness assertions if the time-synchronization protocol comes
-unstuck.
-
-The hardclock() fragment is inserted in the hardware timer interrupt
-routine at the point the system clock is to be incremented. The phase
-adjustment (time_adj) is added to the clock phase (time_phase) and
-tested for overflow of the microsecond. If an overflow occurs, the
-microsecond (tick) in incremented or decremented.
-
-The second_overflow() fragment is inserted at the point where the
-microseconds field of the system time variable is being checked for
-overflow. On rollover of the second the maximum error is increased by
-the tolerance. The time offset is divided by the phase weight (SHIFT_KG)
-and time constant. The time offset is then reduced by the result and the
-result is scaled and becomes the value of the phase adjustment. The
-phase adjustment is then corrected for the calculated frequency offset
-and a fixed offset FINETUNE which is a property of the architecture. On
-rollover of the day the leap-warning indicator is checked and the
-apparent time adjusted +-1 s accordingly. The gettimeofday() routine
-insures that the reported time is always monotonically increasing.
-
-The simulator can be used to check the loop operation over the design
-range of +-128 ms in time error and +-100 ppm in frequency error. This
-confirms that no overflows occur and that the loop initially converges
-in about 50-60 minutes for timer interrupt rates from 50 Hz to 1024 Hz.
-The loop has a normal overshoot of about seven percent and a final
-convergence time of several hours, depending on the initional frequency
-error.
-
-3.3. Leap Seconds
-
-The leap-warning condition is determined by the synchronization protocol
-(if remotely synchronized), by the timecode receiver (if available), or
-by the operator (if awake). The time_status value must be set on the day
-the leap event is to occur (30 June or 31 December) and is automatically
-reset after the event. If the value is TIME_DEL, the kernel adds one
-second to the system time immediately following second 23:59:58 and
-resets time_status to TIME_OK. If the value is TIME_INS, the kernel
-subtracts one second from the system time immediately following second
-23:59:59 and resets time_status to TIME_OOP, in effect causing system
-time to repeat second 59. Immediately following the repeated second, the
-kernel resets time_status to TIME_OK.
-
-Depending upon the system call implementation, the reported time during
-a leap second may repeat (with a return code set to advertise that fact)
-or be monotonically adjusted until system time "catches up" to reported
-time. With the latter scheme the reported time will be correct before
-and after the leap second, but freeze or slowly advance during the leap
-second itself. However, Most programs will probably use the ctime()
-library routine to convert from timeval (seconds, microseconds) format
-to tm format (seconds, minutes,...). If this routine is modified to
-inspect the return code of the gettimeofday() routine, it could simply
-report the leap second as second 60.
-
-To determine local midnight without fuss, the kernel simply finds the
-residue of the time.tv_sec value mod 86,400, but this requires a messy
-divide. Probably a better way to do this is to initialize an auxiliary
-counter in the settimeofday() routine using an ugly divide and increment
-the counter at the same time the time.tv_sec is incremented in the timer
-interrupt routine. For future embellishment.
-
-4. Proposed Application Program Interface
-
-Most programs read the system clock using the gettimeofday() system
-call, which returns the system time and time-zone data. In the modified
-5000/240 kernel, the gettimeofday() routine calls the microtime()
-routine, which interpolates between hardware timer interrupts to a
-precision of +-1 microsecond. However, the synchronization protocol
-provides additional information that will be of interest in many
-applications. For some applications it is necessary to know the maximum
-error of the reported time due to all causes, including those due to the
-system clock reading error, oscillator frequency error and accumulated
-errors due to intervening time servers on the path to a primary
-reference source. However, for those protocols that adjust the system
-clock frequency as well as the time offset, the errors expected in
-actual use will almost always be much less than the maximum error.
-Therefore, it is useful to report the estimated error, as well as the
-maximum error.
-
-It does not seem useful to provide additional details private to the
-kernel and synchronization protocol, such as stratum, reference
-identifier, reference timestamp and so forth. It would in principle be
-possible for the application to independently evaluate the quality of
-time and project into the future how long this time might be "valid."
-However, to do that properly would duplicate the functionality of the
-synchronization protocol and require knowledge of many mundane details
-of the platform architecture, such as the tick value, reachability
-status and related variables. Therefore, the application interface does
-not reveal anything except the time, timezone and error data.
-
-With respect to NTP, the data maintained by the protocol include the
-roundtrip delay and total dispersion to the source of synchronization.
-In terms of the above, the maximum error is computed as half the delay
-plus the dispersion, while the estimated error is equal to the
-dispersion. These are reported in timeval structures. A new system call
-is proposed that includes all the data in the gettimeofday() plus the
-two new timeval structures.
-
-The proposed interface involves modifications to the gettimeofday(),
-settimeofday() and adjtime() system calls, as well as new system calls
-to get and set various system parameters. In order to minimize
-confusion, by convention the new system calls are named with an "x"
-following the "time"; e.g., adjtime() becomes adjtimex(). The operation
-of the modified gettimexofday(), settimexofday() and adjtimex() system
-calls is identical to that of their prototypes, except for the error
-quantities and certain other side effects, as documented below. By
-convention, a NULL pointer can be used in place of any argument, in
-which case the argument is ignored.
-
-The synchronization protocol daemon needs to set and adjust the system
-clock and certain other kernel variables. It needs to read these
-variables for monitoring purposes as well. The present list of these
-include a subset of the variables defined previously:
-
-long time_precision
-long time_timeconstant
-long time_tolerance
-long time_freq
-long time_status
-
-/*
- * gettimexofday, settimexofday - get/set date and time
- */
-#include <sys/timex.h>
-
-int gettimexofday(tp, tzp, tmaxp, testp)
-
-struct timeval *tp;     /* system time */
-struct timezone *tzp;   /* timezone */
-struct timeval *tmaxp;  /* maximum error */
-struct timeval *testp;  /* estimated error */
-
-The settimeofday() syntax is identical. Note that a call to
-settimexofday() automatically results in the system being declared
-unsynchronized (TIME_BAD return code), since the synchronization
-condition can only be achieved by the synchronization daemon using an
-internal or external primary reference source and the adjtimex() system
-call.
-
-/*
- * adjtimex - adjust system time
- */
-#include <sys/timex.h>
-
-int adjtimex(tp, tzp, freq, tc)
-
-struct timeval *tp;     /* system time */
-struct timezone *tzp;   /* timezone */
-long freq;              /* frequency adjustment */
-long tc;                /* time constant */
-
-/*
- * getloop, setloop - get/set kernel time variables
- */
-#include <sys/timex.h>
-
-int getloop(code, argp)
-
-int code;               /* operation code */
-long *argp;             /* argument pointer */
-
-The paticular kernal variables affected by these routines are selected
-by the operation code. Values presently defined in the header file
-timex.h are as follows:
-
-#define TIME_PREC 1     /* precision (log2(sec)) */
-#define TIME_TCON 2     /* time constant (log2(sec) */
-#define TIME_FREQ 3     /* frequency tolerance  */
-#define TIME_FREQ 4     /* frequency offset (scaled) */
-#define TIME_STAT 5     /* status (see return codes) */
-
-The getloop() syntax is identical.
-
-Comments welcome, but very little support is available:
-
-David L. Mills
-Electrical Engineering Department
-University of Delaware
-Newark, DE 19716
-302 831 8247 fax 302 831 4316
-mills@udel.edu
diff --git a/usr.sbin/xntpd/kernel/chuinit.c b/usr.sbin/xntpd/kernel/chuinit.c
deleted file mode 100644
index 77a4cd2..0000000
--- a/usr.sbin/xntpd/kernel/chuinit.c
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
-**	dynamically loadable chu driver
-**
-** $FreeBSD$
-**
-**	william robertson <rob@agate.berkeley.edu>
-*/
-
-#include <sys/types.h>
-#include <sys/conf.h>
-#include <sys/errno.h>
-#include <sys/stream.h>
-#include <sys/syslog.h>
-
-#include <sun/openprom.h>
-#include <sun/vddrv.h>
-
-extern int findmod();		/* os/str_io.c */
-
-extern struct streamtab chuinfo;
-
-struct vdldrv vd = {
-     VDMAGIC_USER,
-     "chu"
-  };
-
-
-int
-xxxinit(function_code, vdp, vdi, vds)
-unsigned int function_code;
-struct vddrv *vdp;
-addr_t vdi;
-struct vdstat *vds;
-{
-     register int i = 0;
-     register int j;
-
-     switch (function_code) {
-	case VDLOAD:
-
-	  if (findmod("chu") >= 0) {
-	       log(LOG_ERR, "chu stream module already loaded\n");
-	       return (EADDRINUSE);
-	  }
-
-	  i = findmod("\0");
-
-	  if (i == -1 || fmodsw[i].f_name[0] != '\0')
-	    return(-1);
-
-	  for (j = 0; vd.Drv_name[j] != '\0'; j++)	/* XXX check bounds */
-	    fmodsw[i].f_name[j] = vd.Drv_name[j];
-
-	  fmodsw[i].f_name[j] = '\0';
-	  fmodsw[i].f_str = &chuinfo;
-
-	  vdp->vdd_vdtab = (struct vdlinkage *)  &vd;
-
-	  return(0);
-
-	case VDUNLOAD:
-	  if ((i = findmod(vd.Drv_name)) == -1)
-	    return(-1);
-
-	  fmodsw[i].f_name[0] = '\0';
-	  fmodsw[i].f_str = 0;
-
-	  return(0);
-
-	case VDSTAT:
-	  return(0);
-
-	default:
-	  return(EIO);
-     }
-}
diff --git a/usr.sbin/xntpd/kernel/clkinit.c b/usr.sbin/xntpd/kernel/clkinit.c
deleted file mode 100644
index 9dae10d..0000000
--- a/usr.sbin/xntpd/kernel/clkinit.c
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
-**	dynamically loadable clk driver
-**
-** $FreeBSD$
-**
-**	william robertson <rob@agate.berkeley.edu>
-*/
-
-#include <sys/types.h>
-#include <sys/conf.h>
-#include <sys/errno.h>
-#include <sys/stream.h>
-#include <sys/syslog.h>
-
-#include <sun/openprom.h>
-#include <sun/vddrv.h>
-
-extern int findmod();		/* os/str_io.c */
-
-extern struct streamtab clkinfo;
-
-struct vdldrv vd = {
-     VDMAGIC_USER,
-     "clk"
-  };
-
-
-int
-xxxinit(function_code, vdp, vdi, vds)
-unsigned int function_code;
-struct vddrv *vdp;
-addr_t vdi;
-struct vdstat *vds;
-{
-     register int i = 0;
-     register int j;
-
-     switch (function_code) {
-	case VDLOAD:
-
-	  if (findmod("clk") >= 0) {
-	       log(LOG_ERR, "clk stream module already loaded\n");
-	       return (EADDRINUSE);
-	  }
-
-	  i = findmod("\0");
-
-	  if (i == -1 || fmodsw[i].f_name[0] != '\0')
-	    return(-1);
-
-	  for (j = 0; vd.Drv_name[j] != '\0'; j++)	/* XXX check bounds */
-	    fmodsw[i].f_name[j] = vd.Drv_name[j];
-
-	  fmodsw[i].f_name[j] = '\0';
-	  fmodsw[i].f_str = &clkinfo;
-
-	  vdp->vdd_vdtab = (struct vdlinkage *)  &vd;
-
-	  return(0);
-
-	case VDUNLOAD:
-	  if ((i = findmod(vd.Drv_name)) == -1)
-	    return(-1);
-
-	  fmodsw[i].f_name[0] = '\0';
-	  fmodsw[i].f_str = 0;
-
-	  return(0);
-
-	case VDSTAT:
-	  return(0);
-
-	default:
-	  return(EIO);
-     }
-}