Is it time to plan a move to Go?

[Hal Murray]

> Thoughts?

Is Go well supported on ARM?  (how about powerpc which is other-endian?)

> * libntp is a problem - ideally we want to have the Python extension
>   that wraps it call compile Go rather than C, but that could be
>   difficult to arrange. 

Why do we need a python extension?  Can't we convert ntpclients to Go?  (and 
drop python)

> * Not hard to see how to qualify most of the translation, but refclock
>   drivers we don't have test hardware for are a source of worry. Can
>   we do anything other than be meticulous and hope? 

Maybe that would be a good time to split the refclocks out to separate 
programs.

I don't have any good ideas.  My straw man would be a pipe rather than SHM.  
There is no wakeup on SHM.

--------

Here is a quarter baked idea.

Write a dumb NTP server in Go.  The idea is to move ntpd to a different port 
number so the new code can answer client requests.  This assumes that a 
server can get all the info it needs from the kernel.  That may be bogus, but 
I think it's worth a try.  We could write similar code in c and compare 
performance.

The idea is to start with a single threaded version, then add multi-threads.

I want the c version anyway.  The idea is to get multi-thread support without 
a major rewrite of the existing code.  It seems like a valuable experiment.

Should this happen before or after we have real crypto working?  If crypto 
uses lots of CPU cycles the difference between c and Go won't matter as much.



-- 
These are my opinions.  I hate spam.