[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)

Danny Mayer mayer at ntp.isc.org
Sun Feb 8 04:36:49 UTC 2009

Harlan Stenn wrote:
>>>> 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
> Martin> net.c.
> 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
> Danny> there.
> 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.

No, I'm not wrong. The design was done by some of the sharpest
programmers in the business. These were not your average programmers. I
worked with them to get this done over several years. You'd be hard put
to improve over the layout. ntp is structurally deficient in comparison.
Fix the ntp structure before you try and improve on ISC's.

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

Probably, but there is nothing you need to do to use the libisc library
for other applications.

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

I could have imported the whole library but I didn't want to spent my
time doing that when I needed only a few modules. The second part of
this is that you would want to modify a lot of the ntp code to make use
of it and that's a large job even if you could persuade everyone to use
it and follow the rules laid down in order to provide the most benefit.
Remember that I work with this code on a regular basis and I understand
how a lot of it works and what I need to do in my own code do pass
muster. ISC code reviews are fierce and each module change is closely
scrutinized and criticized.

> Exactly what does it cost us to work with ISC to get libisc/ be an easier
> tearoff and then use the entire beast, unchanged?

Like I said it's already there. I'm not sure what else you expect them
to need to do.

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

Well the ISC config process already does that. However for each module
you need to add or not add manually whatever is needed. That goes for
Windows too.

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

I don't know since we don't know the specifics.


More information about the questions mailing list