[ntp:questions] new driver development

David L. Mills mills at udel.edu
Wed Mar 30 13:48:08 UTC 2011


Bruce,

You have completely missed the point. The war to minimize the number of 
drivers has not always been successful, but does represent many hours of 
work on my part to update all the drivers when some minor detail of the 
common interface has changed over the last thirty years. Your reference 
to April Fool does not help when assessing your credibility.

Dave

Bruce Lilly wrote:

>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 at lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>  
>




More information about the questions mailing list