> > And I think that people shoot themselves in their own foot when
> > complaining about some alpha code not working for Linux without
> > having made some contribution to that code. As a natural reaction the
> > maintainer wants to get rid of the complaints.
> >
> > Incompatibilities between libc5 and libc6 add another complexity. For
> > historical reasons Linux uses one syscall (adjtimex) where the other
> > systems seem to use three (adjtime, net_adjtime, ntp_gettime). This
> > makes the autoconf stuff complicated.
>
> When I reported problems (several months ago) re xntp3-5.91 (or maybe
> a bit earlier) I got the impression that they didn't have a Linux
> machine to test code on. As the autoconfiscation was still being done
> to the code (it was much worse before) it was clear that in some
> places the code tested for one thing and elsewhere tested for the
> other. My solution to the lack of ntp_adjtime() etc was to provide
> dummy functions of those names which called adjtimex() to do the work
> so emulating the old API which xntpd expected. I even submitted
The real solution would be to implement these in the C library in a
way that they really work. Unfortunately <timex.h> has some problems
of its own (e.g. namespace). adjtimex is a kernel function that
should be hidden from application programs such as NTP programs.
> patches to them to make it build perfectly (on libc5 at least).
They built, yes. Thanks.
> All these things could be hidden away in libc if we wanted to provide
> the interface that ntp expects.
>
> I then got distracted with the Alpha 1024Hz problem which was causing
> ntp to be unable to set the clock right. I'm happy with my hack
> solution even if it isn't the cleanest in the world...
Wasn't that a kernel problem (tickadj == )?
>
> I've not tried ntp4 since out ntp3 systems seem to be rock solid. I'd
> hope that they have taken the chance to clean up the ntp sources.
See my postings to comp.protocols.time.ntp from today (if they are
through already)
Ulrich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/