libntpd contents and the build order of doom

[Hal Murray]

Ian said:
> In trying to write tests for nts_client.c I have run into a problem I do  not
> know how to solve, as it involved much of the structure of the  codebase as
> well as the build system.

> Some of the code in nts_client.c calls the dns_take* series of  functions.
> These functions are defined in ntp_proto.c.

> nts_client.c is listed in the build system as part of the libntpd_obj
> target. ntp_proto.c is in the ntpd target.

> When ntpd is built this works because ntp_proto.c in being built, but  when
> the tests are built it is not, and the build fails as a result. 

As Gary suggested, your test environment wants to catch dns_take_*
You probably want them to be no-ops for now, but if you get far enough, that's how the main thread learns the answer from all the work that the DNS or NTS thread has done.

The flow goes like this...

The transmit routine that would normally send a client/request packet, notices the DNS or NTS flag and calls out to a routine that sets up a new thread to do the work.  There is only one DNS/NTS thread, so that has to get checked for.

Communication between main and DNS/NS worker thread is via global variables.

When the worker thread is finished, it leaves info in global variables and sends a signal to the main thread.  The signal handler sets a flag.  The main loop (eventually) notices that flag and calls over to the DNS/NTS module which looks at the global variables and calls back in to the dns_take_ routines.


There is at least one other place where the test routines have a routine to keep the linker happy, but I can't think of what it is.


-- 
These are my opinions.  I hate spam.