[ntp:questions] new driver development
stenn at ntp.org
Fri Mar 18 04:51:40 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
I fix configure headaches for a living. I will help with this. It will
not be all that difficult.
> 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]
This is not a big deal to me. If you prefer, we can refactor the code a
bit to have a top-level refclock_shm.c that is much smaller, and calls
out to rclk_shm_svid.c and rclk_shm_posix.c to handle the appropriate
"guts" in a cleaner fashion.
> 2. it would reduce flexibility for those who wish to compile one flavor
> but not the other
Not really, that's easy to do with a --with- or --enable- option to
> 3. it would not provide for a clean migration mechanism
I don't see this one. If "flag1 0" (the current default) means SVID,
and we decide that "flag1 1" means POSIX, what is the issue? How is
that significantly different from changing 127.127.28.x to 127.127.y.x ?
> 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.
I don't see that there is a pressing need for an SHM driver under
Windows. If there is, we can find somebody who wants to work on it.
> 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.
They are separate issues. We support timespec where it exists. We want
to support timespec under SHM regardless.
> c. see 1a above. autoconf and automake are no joy.
You do not have to do that. See above.
More information about the questions