On Mon, 28 Mar 2011 15:01:13 +0000, David L. Mills wrote:
You may not be aware that all Spectracom devices are supported with one
driver, all TrueTime devices are supported with one driver, all
telephone modem services are supported with one driver, all Austron
devices are supported with one driver, all Heath devices are supported
with one driver and most GPS receivers are supported with one driver.
I'm going to give the benefit of the doubt and presume that that's an
early April Fool's joke:
Spectracom devices involve not one, but multiple drivers:
refclock_acts.c
refclock_irig.c
refclock_wwvb.c
GPS receivers invlove *many* drivers, including at least the following:
refclock_acts.c
refclock_arbiter.c
refclock_as2201.c
refclock_bancomm.c
refclock_fg.c
refclock_gpsvme.c
refclock_hopfpci.c
refclock_hopfser.c
refclock_hpgps.c
refclock_jupiter.c
refclock_mx4200.c
refclock_nmea.c
refclock_oncore.c
refclock_palisade.c
refclock_parse.c
refclock_ripencc.c
refclock_trak.c
refclock_true.c
refclock_wwvb.c
refclock_zyfer.c
...and your reference to all one Austron devices [sic] is contradictory
as the supported Austron device *is* a GPS receiver.
Note also in the above list of GPS drivers that there are two separate
ones for Hopf devices as well as for Trimble GPS devices.
The refclock_heath.c driver in fact supports only one of the two (long
since discontinued) Heathkit receivers, as is well-documented in the
source code, e.g.:
* The GC-1001 II was apparently never tested and, based on a Coverity
* scan, apparently never worked [Bug 689]. Related code has been
disabled.
As for Truetime, the driver opens a serial port and parses the received
text; it does not need to access different types of objects, different
object namespaces, or different APIs -- it's really only one sort of
device
with relatively minor data stream inconsistencies.
With somewhat greater accuracy, you might have said that there is one
driver that supports all supported SVID IPC interfaces.
This happened with many hours of dedicated effort on the part of
refclock developers. You can appreciate the serious pushback in creating
a new driver if a similar one is already available.
One might then ask, as many of the above all merely grab data from a
serial port, why they were not all required to be rolled into a single
driver, such as refclock_parse.c. But then, a quick
glance
at that shows how convoluted things can get...
One might also wonder why there are separate drivers for WWVB receivers,
all using the same type of serial port communications, and all apparently
minor variations derived from the first:
refclock_wwvb.c
refclock_chronolg.c
refclock_dumbclock.c
refclock_ulink.c
... or the ones for various IRIG time code receivers.
In the case of what I have to date proposed, there are no similar
drivers (I looked. Several times). There aren't any that address
the issues outlined in the article which started this thread. There
aren't any that use any form of POSIX IPC. There seems to be some
confusion, probably on the part of those unfamiliar with the differences
between SVID and POSIX shared memory: SVID shared memory and POSIX
shared memory have as much in common as a Yamaha motorcycle and a Yamaha
piano. Less in common than other types of IPC (e.g. semaphores), which
are also quite different and in most cases also incompatible.
An appropriate plan
is
[common interface code]
#ifdef POSIX
...
#else
...
#endif
That implies compiled-in support for one (exclusive-)or another
type of device, i.e. no possibility to use both types. Worse,
it means one build will try to access one type of device given
a particular refclock server configuration, and a build with a
different set of (build) configure options will access a
different type of device given the same (runtime) ntpd
configuration file refclock server pseudo-IP address specification.
In effect, it means that there are two distinct drivers (only one
of which can be incorporated at build time) using a single device
driver number.
Are you really suggesting some sort of build-time configure option
and conditional compilation macro that would replace (e.g.) the
Heathkit driver with something completely different?
If so, in some sense that might not be such a terrible idea; some
products (and in some cases the companies that produced them) have
long since vanished. Likewise for some technologies (e.g. LORAN).
However, it invites confusion when bug reports etc. refer to a device
number that might be different things depending on ntp version and
build options (and please bear in mind the fact that the person
reporting the bug might not be the one who built the executable, as
e.g. in binary distributions).
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
