[ntp:questions] No libntp.so

Kay Hayen kayhayen at gmx.de
Wed Aug 27 22:53:23 UTC 2008

Hello Martin,

thanks for the reply, you wrote:

> As mentioned in another reply it depends on what ntpq has to do during
> those 25 milliseconds. Please be aware that this may include DNS lookups
> which might fail, so the the call would be take until the DNS lookup times
> out.

We are using "ntpq -n" which makes a huge difference for the peers command and 
make all DNS lookups obsolete. We are also not using DNS on these machines, 
but only a hosts file, so normally this couldn't play a role.

> > As we would like do other important stuff in the same process, we would
> > like to do that faster. So I had a look at the source and found that ntpq
> > is using a libntp.a that nobody seems to package though. There is no
> > libntp.so either, we had searched for those initially, but no luck.
> Libntp just contains a couple of functions which are shared between several
> programs of the NTP package, e.g. ntpd, ntpq and others. It is used during
> the build process of the package in order to save compiule time.
> Even if you would be made available als shared object file it would not
> provide the full ntpq functionality.

I have not come to fully understand where the code is that is executed when I 
enter "peers", but it seemed that the encoding and decoding of packets could 
be found there at least. 

But checking now, the RFC 2553 is not the NTP one. Would you happen to know if 
the decoding/encoding of the packets are part of the library? I could not 
identify it right now.

> IMHO it would not make much sense to provide the existing libntp as shared
> object library. There is some ongoing work which will encapsulate the ntpq
> functionality in a shared object library, so it would be easier to use from
> an own application.

Can you point me to that work? It seems like we would want to contribute to 
that effort then.

> However, those calls may also block, so the basic requirement to call those
> functions from an own tread/task would be unchanged.

One would hope that it could provide both kinds of APIs by allowing us to poll 
on the reply receiving socket. That's not normally very hard to refactor code 
that waits for a reply to give back control and continue when the reply comes 
in. Provided of course, the protocol allows questions and replies to be 
matched by another criterion than sequence, can they?

> > The question of course would be: Will you merge such Makefile patches
> > from us in the first place. And do you see any reason why this should not
> > be done like this. After all, it has not been done for a long time
> > already, so possibly this is on purpose?
> >
> > Obviously we hope you will allow us to be good Free Software citizens and
> > let us drop the fork down the road. Will you?
> The question is not basically whether a patch is accepted. In the first
> place the question is whether a patch makes sense at all. As already
> mentioned above I think it does not much sense just to provide libntp
> as .so file.

If it's only based on the fact that the NTP code isn't ready yet, we will be 
happy as it seems that we can work with you to get it there. 

It seems I was overly optimistic when I saw the listing of libntp directory, 
because it included an RFC in file name. Too bad that's not the NTP RFC. :-/

Best regards,
Kay Hayen

More information about the questions mailing list