Replay progress report

[Hal Murray]

esr at thyrsus.com said:
> This scheme depends on the assumption that, before the main loop, intercept
> functions will be called in the exact same order during replay that they
> were during capture.  There's no separate replay interpreter that is
> dispatching events itself, so there is no way to handle a getaddrinfo event.

Ahh.  I think you need a dispatching layer.  DNS is just the tip of the 
iceberg.

You also need to handle timeouts from the select and anything else the normal 
main loop does.  That includes signal handling.  I think most of the signal 
handlers just set a flag then the main loop notices the flag and does the 
work.

Currently, the only interesting signal tells ntpd to exit.

There are signal handlers to incr/decr the debug level.  I think those get "processed" at interrupt level.  That will be hard to intercept.  Do we want to replay debugging stuff?

I think there is an I/O signal handler.  The idea was to grab arriving packets "now" to get a better time stamp in case the CPU is tied up doing crypto, and queue them up for the main loop to process.  That isn't necessary if the kernel time-stamps arriving packets.  I haven't looked for this code.

Refclocks will add another place to dispatch.

You will also need to intercept PPS.

----------

I divide lines in the replay log file into 3 types:
  input - for the dispatcher
    these are generally asynchronous events
  environment - time, random
  output - packets, time adjustments, writes to files (drift, syslog, stats) 

---------

I have half baked code for a signal that will reopen various files:
  log file (for syslog stuff, to cooperate with logrotate)
  leap file
  authentication keys

ntpd checks for a new leap file occasionally.  The signal lets you verify that your new leap file works without having to wait for ntpd to get around to noticing it.

The stats files have their own mechanism to roll over to another file name.

-- 
These are my opinions.  I hate spam.