Pending tasks

Eric S. Raymond esr at
Mon Sep 17 17:34:02 UTC 2018

Apologies for the daelay on this.  Blame it on the Venusian Death Flu.

We have several tasks in front of us on NTPsec. I want to get some
consensus from the tech team, and a strategy call from Mark, on how to
priority-order these things.

1. NTS

We have a funding offer from Cisco.

Blocker: To move on this, we need a detailed interface contract from
Daniel describing how NTPsec needs to talk to his NTS symbiont.


We now have a goal of moving all our client-side code from Python to Go.
Benefits: (1) banish the horror that is Python library directories, (2)
remove a run-time dependency for operators, (3) build competence and
infrastructure for a port of ntpd itself to Go.

There is no blocker on this.  I expect it to be pretty swift and pleasant.
Ian will probably take point.


Since we simplified the input handling and dropped support for async read,
the code in ntpd for managing a ring of packet buffers has been pointless
weight and can all be removed.  This is near the top of Hal Murray's to-do

Benefit: Just dropping more code weight and complexity.  It might make
TICKLESS simpler, because tthe size and gnarliness of the ntp_io.c code
is the main barrier to that one.


The input handling should be rewritten to use a single wildcard UDP
socket rather than one per interface. (Last week, when I was coming
down with the Venusian Death Flu, I misdescribed this as moving to a
single select call and confused Hal a lot.  Sorry, Hal.)

Benefits: Reduce weight and code complexity.  May make TICKLESS simpler; see
above.  With only the wildcard socket to listen on I think we could get rid of
all the routing-socket stuff, which would remove one of the few remaining
porting issues.

However: I need to understand the use cases for virtual interfaces
better (the -I and -L daemon options to ntpd). Those would naturally go
away too.  I don't know if this matters.

We can do this because I found the magic to read the interface it came through
from a UDP packet.  Which brings us to...


Remove filtering by interface.  This was formerly a blocker on WILDCARD, but
is no longer.  Mark has made a good argument that we ought to rip out all
internal packet filtering in favor of relying on the kernel filter rules.

Benefits: Reduce weight and code complexity. Especially in ntp_io.c; I'd
want to do this before TICKLESS


Remove the once per-second tick in the daemon core, moving to an architecture
entirely based on event queues and timers.

Benefits: reduce power consumption on mobile devices.

This is the final frontier in code-complexity reduction.  It's going to
be difficult, and should probably wait until we're collected the weight

Imporant qustion: have I missed anything?
		<a href="">Eric S. Raymond</a>

"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
        -- Mohandas Gandhi, An Autobiography, pg 446

More information about the devel mailing list