[ntp:hackers] Re: refclock_atom.c

Brian Utterback brian.utterback at sun.com
Tue Dec 14 07:04:42 PST 2004


Harlan Stenn wrote:

>Dave,
>
>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
>#include?
>
>
>>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:
>
>libntp/lib_strbuf.h
>libntp/log.h
>ntpd/jupiter.h
>ntpd/ppsapi_timepps.h
>ntpd/refclock_palisade.h
>ntpdate/ntpdate.h
>ntpdc/ntpdc.h
>ntpq/ntpq.h
>util/jitter.h
>
>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
>files.
>
>
>>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
>SYS_AUDIOIO, SUN_AUDIOIO, MACHINE_SOUNDCARD, and SYS_SOUNDCARD.  In
>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.
>
>H
>_______________________________________________
>hackers mailing list
>hackers at support.ntp.org
>https://support.ntp.org/mailman/listinfo/hackers
>
Please note that for any problems in Solaris at all relative to NTP, I am
happy to file bugs and drive them to be fixed. I cannot always guarantee
the solution proposed (since Sun has other considerations besides NTP),
nor can I guarantee patches will be released (I can always fix things in
the next version, but patches require a risk/benefit analysis), but
I will do my best to make all parties happy.

So, please let me know anything that you feel is broken in Solaris.

-- 
blu

I voted electronically...I think.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

-------------- next part --------------

*****
NOTE: An attachment named brian.utterback.vcf was deleted from this message because it contained a windows executableor other potentially dangerous file type.Contact the system administrator for more information.


More information about the hackers mailing list