[ntp:hackers] new config parsing code

Brian Utterback brian.utterback at sun.com
Wed Apr 25 12:38:24 PDT 2007

Right. My plan exactly. My comment about not caring about the
simulator is only regarding being a Solaris deliverable. I have
every confidence that the linking problems will be solved, but
they will not prevent my delivering the rest of the binaries.

David L. Mills wrote:
> Brian,
> The simulator is only an interface to the actual daemon and is tightly 
> integrated in the source code. It is enabled at compile time by a 
> confuguration keyword. This is the same case as with the current NTP 
> distribution.
> The simulator tool has been a vital component in the past for debugging 
> things impractical to test in vivo. The actual code between the ifdefs 
> could be removed, but this would raise serious problems in maintenance 
> and support and result in two streams of bugfixes. Better to leave it in 
> and never divulge the enabling configuration keyword.
> Dave
> Brian Utterback wrote:
>> Is the simulator something that I would want to ship to my customers,
>> or something I use to verify and/or diagnose NTP's behavior on a
>> particular OS rev? If so, I might be inclined to pass it around 
>> internally at Sun, but not to ship in to customers. If I am wrong,
>> then help me to understand the customer usage of the simulator.
>> David L. Mills wrote:
>>> Brian,
>>> So far as I am concenred, the simulator is an integral component in 
>>> the distribution, especially as it has enhanced functionality over the 
>>> previous version. As you say Sun will not include it in their 
>>> distribution, I assume Sun will commit such resources as to maintain a 
>>> separate corporate distibution. In that case, I assume Sun will commit 
>>> such resources to aid in the related development effort.
>>> You should be reminded that Digital did commit a warm body to aid in 
>>> the development of NTPv3.
>>> Dave
>>> Brian Utterback wrote:
>>>> Harlan Stenn wrote:
>>>>> Folks,
>>>>> Sachin has almost finished the beast.  To our knowledge the last issue
>>>>> that needs to be resolved is a linker problem building ntpdsim.  (There
>>>>> are functions defined in libntp.a that we want to override for ntpdsim
>>>>> by creating copies in a .o file, and the linker is seeing both and
>>>>> complaining instead of using the versions in the .o file and ignoring
>>>>> the later definitions in the .a file.)
>>>>> I can either commit the code now and we work on fixing this linker 
>>>>> issue
>>>>> ASAP, or I can wait until we resolve the link problem before committing
>>>>> the code.
>>>>> Any preferences out there?
>>>>> H
>>>>> _______________________________________________
>>>>> hackers mailing list
>>>>> hackers at support.ntp.org
>>>>> https://support.ntp.org/mailman/listinfo/hackers
>>>> I vote for sooner, but I have a vested interest in getting it done 
>>>> soon and have no such
>>>> interest in the simulator since we will not be delivering it.
>>> _______________________________________________
>>> hackers mailing list
>>> hackers at support.ntp.org
>>> https://support.ntp.org/mailman/listinfo/hackers
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers


"Remember 'A Thousand Points of Light'? With a network, we now have
a thousand points of failure."
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

More information about the hackers mailing list