Removing the worst cruft

Hal Murray hmurray at
Sun Jul 24 02:05:50 UTC 2016

esr at said:
> But AUSTRON/IRIG/CHU...I think there's a good (though not absolutely
> dispositive) case for simply dropping them all.

The Austron driver uses Loran.   It was unplugged in the US several years 
ago.  I think it's still used in Northern Europe.  It may come back in the US 
as a backup for GPS.


Is this a good time to setup a procedure for second class refclocks?  Or 
think about how to do it?

I haven't given this a lot of thought.  The idea is to make it easy to add 
drivers for hardware we don't support directly.

I think there are two things we would have to do.  One is keep track of 
names.  The other is to setup and document a recipe for adding a driver.

Handwave.  My straw man is that the keep-track of numbers part means that we 
maintain everything but the code and documentation for a driver.  I think 
that's just a table entry in pylib/ and another in 
ntpd/refclock_conf.c  It would be nice to teach waf to make man/web pages for 
optional drivers.

It's possible that some git magic would simplify most of that, but I don't 
know how to do it.  Maybe we just maintain a comment that git can replace.  ??

If you use dumbclock as an example, I'll adopt the IRIG driver as a sanity 


How many of the current drivers can we test?  Maybe we should move all the 
others to second class status.

We need a web page with a status slot for each driver.

We should pick one driver to use as an example.  Simpler is better.

If you do dump drivers that have survived this far, I think it would be 
better to move them to another git repository where they are still visible 
but don't clutter up our main world.

Plan B is to not waste time on any of that and save our energy for the great 
SHM cleanup, or whatever.

These are my opinions.  I hate spam.

More information about the devel mailing list