[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
stenn at ntp.org
Sun Feb 8 01:17:12 UTC 2009
>>> In article <498DD696.5020407 at ntp.isc.org>, mayer at ntp.isc.org (Danny Mayer) writes:
Martin> BTW, the same basic problem is with the ISC libraries, which also
Martin> seem to have been copied e.g. from ISC's bind. Nowadays there a
Martin> different versions of the same source code modules both in libisc/
Martin> and ports/winnt/libisc, e.g. interfaceiter.c, isc_strerror.c, and
Harlan> This was a mistake IMO, and there should have been a single
Harlan> codebase. I believe the reason for it is that in the stock ISC
Harlan> libisc/, there are subdirs for unix/ and win32/ and when Danny(?)
Harlan> did the initial import of libisc the main codebase was flattened a
Harlan> bit and it contains the Unix code, and the ports/winnt/ subtree
Harlan> contains the win32/ code.
Danny> No, this is intentional and by design. One of the goals was to get
Danny> rid of as many macros as possible and put O/S required differences in
Danny> separate models and the configuration code will pick the right one. I
Danny> would not like to try and integrate this into one module it would
Danny> make a total mess and it would also make importing newer versions of
Danny> the ISC code much more difficult. Trust me you don't want to go
I think you are dead wrong on this Danny, and next time we're trying it my
way. In particular, we must have an easier way to import new releases from
ISC, and I want to make sure that whenever possible, ISC takes back any
patches we have.
Harlan> This should get better when ISC releases libisc as a
Harlan> tearoff/standalone library.
Danny> It's standalone now. That was part of the original design.
We have different definitions of "standalone" then.
Harlan> My intent is to import libisc as a single unit, and this will affect
Harlan> the build scripts for Windows.
Danny> Not really. We will only include what we need and we are doing that
Danny> anyway. I chose not to try and include all of the modules in both
Danny> Windows and Unix, as we are only using a few functions right now.
Exactly what are we saving by having somebody take the ISC code, figure out
what parts we don't need, and what parts need to be moved from their "stock"
locations to where the would live in the current NTP tree?
Exactly what does it cost us to work with ISC to get libisc/ be an easier
tearoff and then use the entire beast, unchanged?
If there are modules we do not need, then the "configure" process should
disable them and they will not even suck up space in the generated
Martin> IMHO this is also quite error prone. E.g. There are 5 (!) instances
Martin> of the isc_interfaceiter_create() function in the code base, 3 below
Martin> libisc/, and 2 below ports/winnt/libisc/.
Harlan> Yes, this is Bad and it's on the list of things to resolve.
Danny> No, there is nothing wrong here. Just because you have modules with
Danny> the same functions doesn't mean that you are using more than one of
Danny> them. It's the job of the configuration script to figure out which
Danny> to use.
I suspect there is a combination of violent agreement and "one person's
signal is another person's noise" in this last bit.
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions