[ntp:questions] new driver development

Bruce Lilly bruce.lilly at gmail.com
Fri Mar 18 01:18:18 UTC 2011

On Thu, 17 Mar 2011 13:57:08 +0000, Dave Hart wrote:

> Sounds good, Bruce.  The best way to get that integrated with ntpd is
> first integrate it with the existing refclock_shm.c, so that both
> flavors of shared memory are supported by a single driver.  That allows
> us to integrate the new driver without adding as much to the maintenance
> burden of carrying around so many different drivers.

I believe that's a non-starter for several reasons:
1. SVID and POSIX shared memory are quite different. Trying to 
incorporate both in one driver is likely impractical because:
  a. either it will present a configure headache as well as a maze of 
intertwined #ifdefs that will present a maintenance headache
  b. it will fail to build on systems that have the necessary support for 
SVID shared memory but not for POSIX shared memory
  c. vice-versa
  [ of 417 lines in refclock_shm.c and currently 304 lines in my 
implementation (built and tested on Linux x86 and x86_64 and FreeBSD x86) 
there are fewer than 35 non-blank lines that are even close to similar, 
and many of those are #include lines common to most drivers]
2. it would reduce flexibility for those who wish to compile one flavor 
but not the other
3. it would not provide for a clean migration mechanism
4. (last and least) I have no interest in pursuing that path; I'd rather 
drop the effort entirely:
  a. the WINNT stuff in refclock_shm is alien and untestable by me (been 
there, done that, found and reported MS implementation bugs over a decade 
ago that remain unfixed (AFAIK) today). I've migrated away from MS and 
won't be going back.
  b. I looked first at modifying the existing driver; ns support implies 
(POSIX) struct timespec rather than struct timeval [see additional 
relevant comments in a separate response to Harlan Stenn's post] -- part 
SVID, part POSIX makes little sense compared to using a proper POSIX mutex 
and POSIX shared memory in addition to POSIX struct timespec.
  c. see 1a above. autoconf and automake are no joy.

>  I realize that is
> in conflict with your goal of supporting only POSIX systems, but then,
> so is ntpd in general.  Don't be surprised to see me extend your
> named-shared-memory driver to work on Windows one day...

If MS POSIX compliance claims are true, then no "extension" is necessary.
Otherwise, the proper place for any changes (if possible at all) is IMO 
firstly in the lap of the vendor, and secondly in "missing" or "ports".

Beyond that, I wouldn't expect a POSIX driver to work on a non-POSIX-
compliant system any more than I'd expect a Motorola GPS driver to work 
with a Garmin (or Magellan, ...) device.  Indeed, a major advantage of
separate drivers is that only the ones required need be built.

More information about the questions mailing list