[ntp:questions] ntpdate, sntp and libraries
martin.burnicki at meinberg.de
Mon Feb 9 12:14:47 UTC 2009
Danny Mayer wrote:
> [I changed the subject line to reflect the discussion]
> Martin Burnicki wrote:
>> The problem with ntpdate is that code which is used in several programs
>> of the NTP package (ntpd, ntpdate, ntptimeset, ...) has been *copied*
>> from one program to another instead of putting it into a commonly used
>> source file, e.g. in libntp. Over the years changes have been applied to
>> the code in ntpd, but those changes have not made their way into the
>> other programs of the package.
> We are agreed on this and we should be pushing more code into libntp.
> Having said that libntp also needs to be cleaned up.
>> Recently sntp has been written from scratch. So this a pretty new code
>> base. However, AFAIK this did not compile e.g. under Windows, and in the
>> mean time the author/maintainer has disappeared.
> Are you talking about the gsoc-sntp code you mention next?
No, the above referred to the first implementation of the SNTP subproject.
>> Now gsoc-sntp is there, and I don't see how this could be built e.g.
>> under Windows. What I see is that a number of functions which are
>> available in ntpd and can be used both under Unix and windows have again
>> been duplicated/rewritten in gsoc-sntp. So there is one more code base
>> which needs to be ported and maintained. Great.
> We can get it working under Windows.
Of course. However, AFAICS it doesn't work right now, so it has to be ported
to Windows first, and all the things which have already been done in the
original NTP code (Windows vs. Unix/Posix API names and parameters,
WSAGetLastError() vs. errno, log mechanisms, ...) have to be done once more
for the (GSOC-) SNTP code.
IMHO a better solution would be to clean up the NTP code, put more commonly
used functions into a library, and use those library functions for all NTP
subprojects instead of re-inventing the wheel and having to debug/maintain
several functions which do the same things.
>> BTW, the same basic problem is with the ISC libraries, which also seem to
>> have been copied e.g. from ISC's bind. Nowadays there a different
>> versions of the same source code modules both in libisc/ and
>> ports/winnt/libisc, e.g. interfaceiter.c, isc_strerror.c, and net.c.
> Those are different code and that is deliberate. You should look at how
> we designed the directory structure in BIND9 to best deal with the
> various operating system requirements.
The problem I'm seeing is that the different versions seem to be from the
same original code (see the RCS version numbers). If you find an OS
specific bug then you fix it in the OS specific file, but if you find a
general bug you may need to fix it in the file for any supported OS, and
you simply may forget one.
IMHO the code could be maintained much easier if there's only one function
which does the same thing, and there should also be one instance of a
specific header file.
For example, there's include/isc/int.h with RCS version v1.11 and
ports/winnt/include/isc/int.h with RCS version v1.10. Normally I would
think I can upgrade everything to v1.11, and use v1.11 everywhere in the
project, but the diff between those versions indicates this would not work.
If the 2 versions are unchanged as imported from ISC I'd blame the ISC's
maintainer of that file. However, it looks like these this file have been
updated/modified inside the NTP project. This lets the code diverge more
and more, and it makes it nearly impossible to pull updated library files
from ISC into the NTP project.
I'd prefer the method which Harlan has mentione in one of his replies to use
the ISC files as-is, and send changes/bug fixes back to the ISC so they can
pick it up in their code base.
This would let both NTP and ISC benefit from the changes.
I would agree it makes sense to put Windows specific modules of a library
below ports/winnt, but only to implement OS specific helper functions which
are not in the main module, not to duplicate functions from the main
> The Windows directory structure
> is different on ntp because I didn't want to change it fit the BIND9
> structure into it.
>> IMHO this is also quite error prone. E.g. There are 5 (!) instances of
>> the isc_interfaceiter_create() function in the code base, 3 below
>> libisc/, and 2 below ports/winnt/libisc/.
> Yes, there are different versions of isc_interface_create() and friends
> but each is due to different requirements of the operating systems to
> get a list of interfaces. You will find that although it looks like
> separate files, the Unix versions incorporate functions that are common
> to all of them. Again by design. There is only one version under
> ports/winnt/libisc/. Where are you seeing more?
My example has not been related to a specific file, but to a specific
function which is implemented 5 times, in different source modules. Just
grep for isc_interfaceiter_create.
More information about the questions