[ntp:hackers] Re: refclock_atom.c

Harlan Stenn stenn at www.ntp.org
Tue Dec 14 00:33:12 PST 2004


Are we in violent agreement?

> The entire functionality of the PPSAPI is contained entirely in the 
> /usr/include/sys/timepps.h

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."

> 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)?

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

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

> 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

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

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 
> ../include?

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

> 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 
> use.

Please be specific.  What doesn't work anymore or is spurious?

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

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.

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 
> maintenance.

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.

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

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

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


More information about the hackers mailing list