[...]
>
> As I understand Dave's position, we won't change our sys/timex.h, but we
> can accomodate changes to ntptime.c and ntp_loopfilter.c . I believe
> Dave's position is that the only way to achieve Joy in this case is to
> either:
>
> - rename the Linux version of sys/timex.h to something else and use
> __adjtimex(), or
>
> - implement a conforming xntp interface in Linux, using either
> NTP_SYSCALLS_LIBC or NTP_SYSCALLS_STD. I suspect this may require
> renaming "your" sys/timex.h, or at least provide for different
> structure names in there.
I'd vote for the second solution, even if it takes some time and
produces incompatibilities, but I guess those who use __adjtimex can
also handle the new situation.
>
> Harlan> Question: For what values returned by config.guess is KERNEL_PLL
> Harlan> is expected to work?
>
> Torsten> Anything above 1.2 should be fine as long as you don't insist
> Torsten> on PPS.
The -DPLL will only work with the 2.0 kernel, because the daemon
tries to display PPS variables even if PPS is not compiled in (to the
daemon).
>
> OK, I still need the output of config.guess .
Just assume that everything above or equal 2.0.0 will work.
>
> Harlan> If a working KERNEL_PLL for Linux requires *both* certain
> Harlan> releases of the kernel (as identified by config.guess) *and*
> Harlan> particular revisions of libc, I'm going to need somebody to
> Harlan> write the configure.in test that identifies the version of libc,
> Harlan> and we need to know what version of libc is required for
> Harlan> KERNEL_PLL.
The current "stable" libc is buggy. One solution that comes into my
mind is to create a new short C file that implements the ntp_*
syscalls in some way that works _now_ (maybe using the syscall
macros). That way there would be only one point to change if the next
stable libc finally supports ntp_* (or maybe even if the kernel
does).
>
> Torsten> The problem is not the release of libc, but the kernel the
> Torsten> libc-binary was built on (yuck!). Basically, the program in
> Torsten> question (mainly xntpd) will crash and dump core if the kernel
> Torsten> writes a bigger return struct than libc has allocated stack
> Torsten> space for. This amount is determined at compile time via
> Torsten> sizeof(struct timex). I managed to get a README into the libc
> Torsten> sources along with a patch to apply, but unfortunately many
> Torsten> linux distribution "vendors" cannot read. If a libc binary
> Torsten> built on unpatched 1.2 kernel includes gets to run on a newer
> Torsten> (>1.2.30) kernel binary, then adjtime() || ntp_*() => crash
>
> I'm open to suggestions on how to handle this situation.
Well, "customers" should upgrade their libc (or use the solution
described above).
>
> Torsten> [SIGSYS question deleted. 1.2 has the calls and if someone
> Torsten> hasn't upgraded from 1.0.9 or earlier they're unlikely to do so
> Torsten> now]
>
> According to Harald Milz, who says he's running Linux 2.0.10
> (libc.so.5.x.x), this isn't true. He says that SIGSYS isn't there.
In my Linux distribution (German S.u.S.E 4.3#1) this is also true (no
SIGSYS for i386 defined). I don't know why, but it's a fact.
>
> Harlan> I gather that linux does not use either NTP_SYSCALLS_{LIBC,STD}
> Harlan> and instead uses the __adjtimex() call for ntp_adjtime().
>
> Torsten> _It_does_ ! NTP_SYSCALLS_LIBC ! I wonder why this doesn't get
> Torsten> detected - should be easy with autoconf.
>
> According to Harald, NTP_SYSCALLS_LIBC is not being detected under Linux
> 2.0.10 (libc.so.5.x.x).
I don't know about this one, sorry!
[...]
>
> H
>
Ulrich