[ntp:questions] new driver development

Dave Hart davehart at gmail.com
Fri Mar 18 03:13:03 UTC 2011

On Fri, Mar 18, 2011 at 01:18 UTC, Bruce Lilly <bruce.lilly at gmail.com> wrote:
> 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 you don't like it. ;)

> 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
> and/or
>  b. it will fail to build on systems that have the necessary support for
> SVID shared memory but not for POSIX shared memory
> and/or
>  c. vice-versa

If ntpd's configure can be extended to properly support your driver as
a standalone driver, there's approximately zero more work to be done
to properly support your driver integrated with the existing
refclock_shm.c.  That is an informed opinion, I've hand my hands in
our configure scripts more than anyone else recently, and more than
anyone but Harlan Stenn ever, I suspect.

If the headers are incompatible we might use two or three .c files to
build that one driver, but once it's linked, there really is no
difference between #ifdefs in two different drivers and in one.

>  [ 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]

That's not why I suggested it needs to be integrated with an existing,
similar driver.  Perhaps you should survey the existing refclocks and
when their numbers were assigned.  Hint:  The odds of you getting your
driver into the distribution as yet-another-driver are slim at best.

> 2. it would reduce flexibility for those who wish to compile one flavor
> but not the other

Not necessarily.  The driver could be present but refuse to operate in
one or the other modes if the system doesn't support both, or the
builder disabled one type.

> 3. it would not provide for a clean migration mechanism

I don't understand what you're getting at.  Tell me how having a
separate driver number from refclock_shm.c improves things.

> 4. (last and least) I have no interest in pursuing that path; I'd rather
> drop the effort entirely:

First and foremost, IMO.

>  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.

No one asked you to run Windows, but your rant is appreciated for context.

>  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.

Mutex doesn't sound compatible with ntpd's non-blocking design.  It is
not acceptable for ntpd to hang because gpsd crashed.  It's not that
difficult to implement shared memory synchronization in a
producer/consumer arrangement like this using atomic operations.

>  c. see 1a above. autoconf and automake are no joy.

See above, no problem.

>>  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.

I mentioned Windows simply because its shared memory model is closer
to posix (using named shared memory, though not in the filesystem, in
a filesystem-like global namespace).  Thanks again for the rant about
Windows POSIX compliance, though.  I get that you aren't going back.
I didn't ask you to extend your shared memory driver to Windows, I
threatened to do it myself :)

Have fun,
Dave Hart

More information about the questions mailing list