<div dir="ltr">Is there a reason to keep dumbclock? Maybe it exists as a starting framework for when someone wants to write a new clockdriver?<div><br></div><div>..m</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 29, 2017 at 5:36 AM Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here are the full current stats:<br class="gmail_msg">
<br class="gmail_msg">
all 71320 (100.00%) in 298 files<br class="gmail_msg">
c 60694 (85.10%) in 152 files<br class="gmail_msg">
python 7472 (10.48%) in 48 files<br class="gmail_msg">
shell 1444 (2.02%) in 7 files<br class="gmail_msg">
yacc 1255 (1.76%) in 1 files<br class="gmail_msg">
waf 455 (0.64%) in 11 files<br class="gmail_msg">
<br class="gmail_msg">
We're down to a hair over 26% of the original bulk of C. The main<br class="gmail_msg">
possible place to cut that's left is the ntp_io.c code; removing<br class="gmail_msg">
interface scanning and going with one wildcard socket seems likely<br class="gmail_msg">
to cut a couple KLOC. Past that, we're running out of crap to clean<br class="gmail_msg">
up unless we decide to drop more obsolete refclocks or Hal is<br class="gmail_msg">
able to rewrite the async-DNS code and seriously shrink it.<br class="gmail_msg">
<br class="gmail_msg">
Accordingly I've recently done a pass through the reclocks. The<br class="gmail_msg">
dumbclock driver should probably go - it's an obvious dorm-room stunt<br class="gmail_msg">
that doesn't correspond to any production hardware anywhere.<br class="gmail_msg">
Otherwise it's hard to see what else to cut without a policy change.<br class="gmail_msg">
<br class="gmail_msg">
A couple other interesting points:<br class="gmail_msg">
<br class="gmail_msg">
* The size of the waf recipe has been dropping recently. The crypto<br class="gmail_msg">
cleanup helped with that. More needs to be done here; it's still<br class="gmail_msg">
overcomplicated and somewhat buggy.<br class="gmail_msg">
<br class="gmail_msg">
* 10% of the code is now Python. That's better than I thought we<br class="gmail_msg">
would do in terms of moving from C to a memory-safe language (that<br class="gmail_msg">
is, shy of a rewrite in Go or something). It would be good to<br class="gmail_msg">
increase that further, but this is unlikely; what's left in C either<br class="gmail_msg">
needs to be there for performace reasons (ntpd) or would be<br class="gmail_msg">
difficult to shift out of all proportion to its size(ntptime,<br class="gmail_msg">
ntpfrob, sht).<br class="gmail_msg">
<br class="gmail_msg">
* Most of the shell code (975 lines) is autorevision.sh.<br class="gmail_msg">
--<br class="gmail_msg">
<a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" class="gmail_msg" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br class="gmail_msg">
<br class="gmail_msg">
Live free or die; death is not the worst of evils.<br class="gmail_msg">
-- General George Stark.<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
devel mailing list<br class="gmail_msg">
<a href="mailto:devel@ntpsec.org" class="gmail_msg" target="_blank">devel@ntpsec.org</a><br class="gmail_msg">
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br class="gmail_msg">
</blockquote></div>