Is it time to plan a move to Go?
hmurray at megapathdsl.net
Sun Nov 5 00:40:08 UTC 2017
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
> * 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
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
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.
More information about the devel