Re: xntp3-5.8x and Linux

Ulrich Windl (ulrich.windl@rz.uni-regensburg.de)
Thu, 26 Sep 1996 08:16:42 +0200


On 25 Sep 96 at 23:53, stenn@whimsy.udel.edu wrote:

> Folks,
>
> I've received some patches for Linux that don't make sense to me.

The unpleasant tasks of a maintainer... ;-)

>
> Please help me out here, OK?
>
> The problem where Linux was using xntpd's "stock" version of sys/timex.h
> instead of the one hacked for Linux has been fixed as of xntp3-5.86.
>
> We enable KERNEL_PLL iff we find sys/timex.h . Since sys/timex.h is
> found under all versions of Linux, we're always going to enable
> KERNEL_PLL.

I support that opinion. Especially there's a fix for the old (1.2)
kernel to bring it to a corrected version. Meanwhile nobody should
use a 1.3 (development version) any more. All the 2.0 kernels will
have a working PLL.

>
> Now I understand that right now we're fixing some bugs that are
> preventing KERNEL_PLL from working right now. I also read some email
> that suggested that KERNEL_PLL will only work under more recent versions
> of Linux.

A kind of symbiosis is needed: If the kernel is supported, we can
easily find out whether it (the PLL implementation) works ok. A
problem I experienced is that the time between occurrence of a time
interrupt and execution of the PLL code is somewhat variable
(interrupt delays). This adds some jitter under heavy load.

>
> Question: For what values returned by config.guess is KERNEL_PLL is
> expected to work?

Please accept my excuses, but I do know almost nothing about GNU's
autoconfig. Linus Torvalds should know, but I guess all Linux kernels
since about 1.3.20 should be fine (from the PLL view).

>
> If a working KERNEL_PLL for Linux requires *both* certain releases of
> the kernel (as identified by config.guess) *and* particular revisions of
> libc, I'm going to need somebody to write the configure.in test that
> identifies the version of libc, and we need to know what version of libc
> is required for KERNEL_PLL.

As a matter of fact the official "stable" version of libc is buggy
(author notified, problem confirmed). The working solution is to use
a syscall macro (don't know by heart how to do that, but the library
source is available). The problem with libc really is that it tries
to be backward compatible when the returned structure was smaller
(The struct is locally buffered, so BANG!).

>
> I have heard that the x86 version of Linux does not have #define a value
> for SIGSYS, but a non-x86 version of Linux *does* have the #define.

Never found SIGSYS on my Linux-i386 (doesn't mean much; I first saw
SIGSYS in xntp). I think in Linux-i386 you get a SYSSEGV on an
invalid system call. But Linux Torvalds surely knows best. Maybe he
should define SIGSYS as an alias for SYSSEGV (bad idea?)...

>
> Question: What signal does x86 Linux send to a process that a bad system
> call was made if SIGSYS isn't defined?

Good question, but I don't know the answer by heart: Either look it
up it the kernel sources (don't throw eggs at me) or try it (using
gdb).

>
> I gather that linux does not use either NTP_SYSCALLS_{LIBC,STD} and
> instead uses the __adjtimex() call for ntp_adjtime().

That's a point I'm fighting for for some time. Maybe when NTP was not
that much standard the kernel people thought just to "enhance" the
existing adjtime() system call. Currently libc maps adjtime() to
__adjtimex(). I'd support two new system calls for NTP (the ones
defined by Prof. Dave Mills). (Hi Linus!)

>
> Question: Does Linux have ntp_gettime()? If not, what is the
> equivalent?

Not as a system call. The equivalent is __adjtimex(), the "time super
function". (Too bad, I had sent patches for these things to Dave
Mills, but lost all my local xntp sources due to a software problem)
Dave seems to have lost them, too.

>
> I think these questions cover all of the remaining issues for Linux.
>
> Question: Does anybody know of other problems?

Sure: The Kernel has no ready-to-use support for a PPS signal (I
thought about working on that)

>
> Thanks...
>
> H

Ok, I tried to help you.
As I'm not a/the kernel specialist, I'll send copies of my reply to
Linus Torvalds and the kernel hacker list. I assume you don't mind.

(My excused to Dave for also sending a copy to him; he recently
complained about the Linux problems)

Ulrich