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 [email protected] http://lists.ntp.org/listinfo/questions
