Hal Murray <hmur...@megapathdsl.net>:
>
> Eric said:
> >> I've been collecting major items in devel/TODO-NTS
> > Is there some reason this isn't just a section in nts.adoc? (Which may need
> > some GC at this point.) The whole idea of that document was to be a planning
> > whiteboard.
>
> Only signal to noise. I was trying to capture the big ideas without getting
> bogged down in details.
Fair enough. At some point in the near future I need to go through nts.adoc,
cull out the things we've done, and delete roads that won't be taken now.
*I* might merge those documents then. I'll give you a heads-up if I do.
> My big concern is that nobody else seems to be testing it. There may be
> dragons that I haven't poked.
Understood. Unfortunately I myself can't be much help here - my
outside view of NTP is still weak, I have only limited ability to
recognize what normal operation should look like or spot deviations
from it. Gary or Achim or Matt would be better for that end of
things.
> > Remember, I'm trying to get away from configure-time options.
>
> There is a fundamental conflict between ease of use, ease of debugging, and
> good security. I don't know how to resolve that. Mostly, I was trying to
> raise the issue. Configure-time issues are just a detail.
I don't know how to resolve it either, not in any global sense. We'll
just have to muddle through. I don't think we;ve done badly so far.
> For Go, can we build 2 versions by linking in different modules?
We can. That's what build tags allows. Getting the kind of fine-grained
control one has with #ifdefs would be complex, though - outside of regularly
structured cases like a driver table (which should really be handled by
code templating using "go generate") one could easily wind up in a
combinatorial tag explosion.
I strongly suspect that the weaker conditionalization support reflects a
deliberate choice on the part of the Go designers. I think they'd say that
the kind of feature-option trickery we're used to in C builds is a defect
attractor - and think they'd be right to say that.
> Has anybody looked at our configure time options? How many of them make
> sense
> in the context of Go? (ignore refclocks)
It was on my list. Now is not a bad time to look deeper.
Eyeballing the output of ./waf configure help I see
NTP configure options:
--disable-droproot Disable dropping root.
--enable-early-droproot
Droproot earlier (breaks SHM and NetBSD).
--enable-seccomp Enable seccomp (restricts syscalls).
--disable-mdns-registration
Disable MDNS registration.
--enable-classic-mode
Strict configuration and log-format compatibility with
NTP Classic
--enable-debug-timing
Collect timing statistics for debugging.
NTP configure features:
--enable-leap-smear
Enable Leap Smearing.
--enable-leap-testing
Enable leaps on other than 1st of month.
--enable-mssntp Enable Samba MS SNTP support.
Refclock configure options:
--refclock=REFCLOCKS
Comma-separated list of Refclock IDs to build (or "all")
That's not terrible.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
