Hello,
I have some stuff for discussion regarding kernel time in 2.1:
I have made available a patch against 2.1.131 that is basically only a
merge from the corresponding patch against 2.0.36 from "PPSkit-0.3.8".
Still it took me about 7 hours until it seemed to work for the first
time (a few boots and many compiles included).
I want to take this occasion to present this "very alpha(!)" patch to
some interested hackers, and throw in some food for discussion:
I started my work on NTP/PPS/timekeeping support when 2.0 had been
already out. Therefore I had never intended to integrate it into the
standard distribution. That's why it's named "PPSkit". As it turned
out later, there were several bugs in the kernel that would also
affect non-NTP users. Therefore I asked and then decided to split my
kit into a "time fix" patch and an "PPS extension patch". The fix pack
went into 2.0.32. The 2.0 PPSkit will remain at "0.3.x".
For 2.1/2.2 the planned releases are "0.4.x" and "0.5.x": The 0.4
series will add the equivalent of the 0.3 series to the newer
sources. Maybe some inconveniencies could be resolved, too, but I'll
see. The 0.5 series (if ever) will possibly add some new stuff if I
find the time to do so.
The main questions is: Should I try to get an equivalent 2.1 "time
fix" out first, and then offer an additional "extension pack", or can
the whole beast be considered "tested well enough" to be included in
2.1/2.2? If that's the case, my sucessor-patches could be much
shorter.
Now some details: I heavily hacked adjtimex() to check for invalid
parameters, and the semantic of the syscall is that it still can
return valid values in the timex structure even if the return value is
!= 0 (positive to be exact).
The pulse processing also seems to work, and the timestamps don't look
that bad. Unfortunately there seems to be a problem with the serial
driver:
I have a DCF77 clock at home that features "raw output", i.e. it sends
a pulse of 100 or 200ms every second. That pulse is fed into RxD at a
low baud rate, and the different receive characters are used to
reconstruct the original pulses (bits). In 2.0.36 everything works
fine. When I had tested around 2.1.42, it did not work. For 2.1.131, I
have a feature that exactly (it seems) every 10 seconds a pulse is
missed, that is I receive a pulse at DCD, but not a character at
RxD. I once had the inverse in 2.0: receiving only a pusle every 10
seconds, while receiving RxD data just fine. I have walked through
the code in the serial driver, but could not find a reason for that
(in 2.0). Any ideas?
I also wondered whether it would be desirable to conditionally remove
the NTP related stuff from compilation for embedded systems with slow
CPUs or little RAM. It would save a few bytes and cycles at the
expense of a crippled adjtimex function. Would it be worth the
efforts?
In any case, I'd like you to try the patch (enable experimental
features) and tell me your thoughts and outcome...
The location is
ftp://pcphy4.physik.uni-regensburg.de/pub/wiu09524/PPS/PPSkit-0.4.0pre0.diff.bz2
(17960 bytes, format chosen to avoid non-hackers to shoot themselves
in their feet)
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/