announce(i386, experimental): NANOKERNEL (with PPSkit) snapshot #5

Ulrich Windl (ulrich.windl@rz.uni-regensburg.de)
Fri, 5 Mar 1999 09:00:21 +0100


Hello,

I just uploaded "PPSkit-0.6-i386-pre5.diff.gz" to the usual places
(linux.kernel.org/pub/linux/daemons/ntp/PPS, ftp://pcphy4.physik.uni-
regensburg.de/pub/wiu09524/PPS).

This snapshot features clock_getres() similar to POSIX.4, and the
routine is used to set time_precision. Debugging messages in the
problem candidate, hardpps(), were improved, and a quick and dirty
fix seems to work well (ntptime and ntp4.0.91f: stability 0.082ppm,
jitter <5µs, precision 7.5µs, estimated error 1.5µs)

I also moved some time routines from i386/kernel/time.c to
kernel/time.c, because they do not make much sense in the
architecture dependent file.

Stickyness of TIME_ERROR has also been fixed. Setting the time no
longer sets TIME_ERROR, instead it is deduced from STA_UNSYNC.

I have completed most of the important parts, but I'll have to check
some details of hardpps with Dave Mills. I'll use this weekend to
update documentation and utilities, so that a real release comes
definitely closer.

I'll describe the changes made to the time stuff, requesting gurus
for the other architectures to implement nanosecond timeoffsets. I'll
try to merge most of the changes ready for use, but I can't test
these architectures.

One current issue is: For compatibility <linux/sched.h> includes
<linux/time.h> in my snapshot now. Therefore any change in the time
stuff recompiles about everything (e.g. drivers/scsi/sd.c). As many
parts don't really need the <linux/time.h>, I'm considering to take
it away from <linux/sched.h>. Maybe I'll have to add it explicitly
for some files. A compilation will show.

The time code changes are huge, but I think it was time for a major
cleanup. Probably more a candidate for 2.3 than for 2.2, but I think
we can extract some goodies for the stable kernel (if there's demand).

Regards,
Ulrich Windl

-
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/