[ntp:hackers] Re: refclock_atom.c

David L. Mills mills at udel.edu
Tue Dec 14 07:42:28 PST 2004


It would be much easier for me to reply inline if your messages were 
sent in plain ASCII. Netscape insists on formatting inline text and I 
can't read it. So, for each inline comment I have to bludgeon Netscape 
to use fixed width font.


Harlan Stenn wrote:

>Are we in violent agreement?
>>he entire functionality of the PPSAPI is contained entirely in the 
This is true for OSes that provide the PPSAPI there. This is apparently

>>*not* true for SunOS, Solaris, or SCO, where *we* currently provide the
>>header for folks who can use it.
>>I would agree with you if you would have said "... entirely in the
>>timepps.h header."
Just like OpenSSL, the PPSAPI is entirely separate from the NTP 
distribution. Where the headers are not supplied in the stock operating 
system distribution, the NTP distribution might supply them; however, a 
clear disclaimer should be included that says the header files must be 
installed by the user separately from the distribution and that the 
files, if included from the distribution, may not compatible with the 
current version of the operating system.

>>header file specific to each operating 
>>system. All machine dependencies, including Solaris idiosycnrcies, are 
>>contained there. The files on some machnines do change from time to time 
>As in bugfixes/improvements, or something else (like compensating for
>local oddities, or subtle differences in the implementation)?
This has nothing to do with NTP maintenance and is a separate issue.

>>and I just had a runin with something broken on Solaris. To wit, only 
>>the assert and clear bits can be set; nothing else in the mode word, 
>>even though some combinations would work.
>I don't know what you are trying to communicate by this last bit.
I don't know how to be more clear. The timepps.h file, apparently last 
updated by Ulrich Windl, is extravagantly anal retentive in error 
checking and prevents setting the echo bits. What am I "trying to 
communicate?" If it isn't clear, just ignore it.

>>The PPSAPI was specifically designed to be non-NTP centric and we had a 
>>lot of discussion on alternative uses for it. The intent was to put 
>>timepps.h in /usr/include/sys, because that's where machine dependencies 
>>live. Putting it anywhere else is not a good idea. If some OS 
>>distributes it otherwise, we should so advise the kernelmongers.
>OK, I agree with you on the first part.  As for where it lives,
>"we" can suggest, we cannot dictate.  We provide "mechanism" and
>a suggested "policy" (placement).  Where folks put the beast is
>their policy decision.
>The only thing ppsapi-timepps.h does is that it allows folks who have
>supported OSes but no installed timepps.h header to use the PPSAPI for ntpd.
Exactly. Tell those folks where to install the supplied file.

>>Actually, the right place for these files is with the kernel 
>>distribution for each system, not the NTP distribution.
>And how successful have we been getting these files installed in SunOS?
>Solaris?  SCO?
>Are you saying that if timepps-{SunOS,Solaris,SCO}.h are distributed
>somewhere we should *only* use them if somebody takes the trouble to
>install the file under /usr/include/sys/?
>Are any modifications to these headers needed before they are installed
>and used?
>If no modifications are needed, where is the harm of our doing the
No, no, a thousand time no. The user must be aware that this is not a 
standard feature and there might be some hazard in installing it, as 
well as the reponsibility to make sure the file is current and 
compatible as the operating systems evolve. Same issue in keeping 
current with OpenSSL.

>>If crafted files 
>>happen not to be available and they happen to be available at ISC 
>>separately or in a carefully quarantined directory in the NTP 
>>distribution as <<models>> for the real stuff, then stash them with a 
>>readme and note in the build documentation, like OpenSSH is now.
>OpenSSH is maintained by the openssh folks.
>I thought that *we* maintained the versions of timepps-*.h for OSes that
>do not provide them.
We do NOT maintain PPSAPI just as we do NOT maintaint OpenSSL.

>And again, if we are telling somebody to "copy timepps-YourOS.h to
>/usr/include/sys/timepps.h" then exactly how is our getting that file
>from /usr/include/sys/timepps.h different from getting it from
>include/timepps-YourOS.h ?
>Then there is the issue of maintenance.  For the few OSes that "use"
>include/timepps-YourOS.h the odds are that we'll be updating that file
>sooner or later.  If folks have the option to use it from our distribution
>the odds are that they'll get any fixes we happen to install.
>And we'll get fewer support calls because the folks on SunOS, Solaris,
>and SCO will just get the newer (allegedly improved) files instead
>of having to check each time to see if they might have to update a file.
>>In a 
>>final bit of pique, may I strongly suggest that all header files live in 
>The common (shared) ones are.
>The ones that are not are:
>and my preference would  be to move non-shared header files from include/
>to the directory that needs them.
>But these can all be moved to include/ if that's what is desired.
>Personally, I think that will just make it harder to maintain the header
!! If a header file is used by only one program, it does not belong to 
be a header file.

>>This distribution is gettting out of hand. It is full of nasty little 
>>surprises that either don't work anymore or are spurious to the intended 
>Please be specific.  What doesn't work anymore or is spurious?
Look in the scripts directory. My scripts are the worst offenders. Same 
for the line disciplines and streams modules, that haven't worked since 

>>There are a number of things that should live in their own little 
>>grotto, like sntp, electric fence, the ancient stuff in sys, old broken 
>>scripts, etc.
>Well, the good news is that sntp, electric fence, kernel and kernel/sys
>live in their own little grotto, and have lived in them for quite a while.
>I maintain sntp and electric fence, so I know they behave.
These are not part of the NTPv4 software suite. They belong as separate, 
self contained distributions.

>The kernel/ and kernel/sys/ subdirs "do nothing" and I don't maintain those.
>If you (or anybody else) wants something done with kernel/ or kernel/sys/
>just tell me and it will happen.
FIne. Off it.

>What are the old broken scripts, etc. to which you refer?
>>I've been sorely bitten by the low-level system clock 
>>briar patch that I spent quite a lot of time fixing, rationalizing and 
>>clearing weeds only now to see it botched up beyond any hope of my 
>Are you talking about ntp_set_tod() in libntp/machines.c?  There is a
>ton of OS-specific other stuff there, but that particular subroutine
>is pretty clean.  If you prefer I'm happy to split that function out
>into a separate file for you.
>And if you really don't want to mess with it at all, I'm happy to
>agree on an API for that function and I will (continue) to maintain
>that code so you do not have to look at it.
>I spent quite a long time making sure ntp_set_tod() was as simple and
>clean as possible.  I doubt that significant improvement can be made
>with that particular subroutine.
>It also hasn't changed much in 3 years' time.
I think it has been less than three years. Last time I looked there was 
some very seriously broken code there and I pulled weeds mercilessly. 
Since then the the machine specific headers have grown serious weeds. 
Last time I went over the coder for the simulator I simply gave up. I 
use this and the audio stuff as examples in class of extremely poor 
programming practice.

>>Same thing happened to the audio code. This is very, very 
>>wrong. If some systems require substantially different code, then there 
>>should be either hidden in a specific header file like timepps.h, be a 
>>separate module surrounded by ifdefs or a separate file. As it is, the 
>>maze of ifdefs is impossible to unravel.
>The audio code is not something that can be easily handled by a specific
>header file like timepps.h.
>The audio code is handling 5 different mechanisms, in 2 groups.
>In one group, there is PCM_STYLE_SOUND.  In the other group we have
>this latter group, most everything is the same, and some methods need
>to do some small things differently.
>I can probably easily split the code into a PCM audio file and the "other"
>audio file, and I fear that doing this will make it harder to keep the APIs
>consistent and correct.
>The bigger problem is that different OSes that use the same mechanism
>still manage to do things differently, so people are sometimes forced to 
>hack the code to get what they want.
>I think the better solution is to provide for better control over the
>audio subsystem thru the ntp.conf file (or a new ntp.audio.conf file).
>There is an open bug on "rewrite the audio code", bug #291.
The timepps.h approach is clearly the preferred scheme where applicable. 
Twisty turny ifdefs is clearly the worst scheme.

>>I don't want the atom driver or 
>>any other code to get that bad.
>Nobody does.  And it's not likely to happen, as the audio code currently
>supports 5 ways to do its job, and no other subsystem has do deal with
>that level of complexity.
>>I mentioned before that the refclocks local, arbiter, chu, as2201, irig, 
>>wwv, wwvb, pst, atom, heath and tpro, as well as ntp_refclock.c are from 
>>my hand. I am not the maintainer, backup maintainer or substitute 
>>maintainer. I am the ONLY maintainer. If somebody wants to change one of 
>>those, I would be happy to receive advise, bugs or consideration.
>Until we find a way for you to be happy with bugzilla+email (and that
>may never happen), we may need to find a volunteer to "interface" between
>you and bugzilla.  I am already way too busy, and there is no way we're
>going to get people to send some reports to bugzilla and other bugs to you.
>Even if it is possible to "split" the reporting, doing so would mess me
>up on release management.
I'm way too busy, too, and have no patience with bugzilla. If something 
needs fixing and somebody tells me, I will fix it. Frankly, I don't care 
if that messes up your bug tracking, especially if you think a volunteer 
to interface with me is required.

>I track open issues and manage releases based on getting certain bugs
>fixed before making a relase.  I want to be aware of any outstanding
>issues (including any that might be in "your" list) so I can manage
>releases and perhaps offer any assistance to help get the resolved.
>I found a bug in refclock_atom.c today; the declaration for
>atom_shutdown() must happen all the time, not just when HAVE_PPSAPI
>is set.  Do you want to fix that or should I?
You didn't check the latest code. You do not have permission to change 
any of the files I have specifically exempted.

>>Did I mention the current distribution does not compile on porkypine?
>Not before this, but I have fixed it and installed the latest code there.
Postscript. Over the last year I have spent 10-20 hours per week 
carefully nuturing the code, removing and repairing weeds, making and 
testing flow charts and trying to improve the robustness of the code 
with respect to an eventual formal specification. I regard the release 
engineering as seriously flawed in the face of simplicity and 
robustness. It is trying to do too much handholding, too much 
idiosyncratic conformance with broken operating systems and too fragile 
when these systems change. Maintenance has become a black art and only 
about two people in the world can manage it. I certainly can't. So, my 
position will be to fence those files I deem critical, including 
ntp_proto.c and ntp_crypto.c and the refclocks I called out and reserve 
all bugfixes on them for myself. This may get in the way of bugzilla, 
but that's the way it will be.


More information about the hackers mailing list