Closed WorldofJARcraft closed 1 year ago
Looks sane. I take it you've built and successfully tested this on an adjtimex-only system? (I'll give it a run on regular Linux.)
I did a compile test on the latest release of Alpine Linux, which uses musl libc and has adjtimex
but no ntp_adjtime
. I also ran owping and owampd using the adjtimex
interface and got similar times to what I expected.
adjtimex
the Linux-specific alternative to ntp_adjtime
, and according to its documentation, it behaves exactly the same as ntp_adjtime
. The only difference is that the names of the constants allowed for the modes
field are different, but that field is set to 0 by memset
in time.c.
I can run more tests, e.g. with and without ntp synchronization, if you want.
This is a proposal to solve the same problem as the one addressed by #64 in a backward-compatible way. I have updated configure.ac to check for both
ntp_adjtime
andadjtimex
. If both are found oradjtimex
is not found, it usesntp_adjtime
(the current behavior). If onlyadjtimex
is found, it usesadjtimex
(workaround for musl, uClibc, etc.). If none are found, compilation behaves as if thesys/timex.h
header did not exist and does not use ntp.