Removing the worst cruft
hmurray at megapathdsl.net
Sun Jul 24 02:05:50 UTC 2016
esr at thyrsus.com 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/refclock.py and another in
ntpd/refclock_conf.c It would be nice to teach waf to make man/web pages for
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