[ntp:questions] new driver development

Harlan Stenn stenn at ntp.org
Fri Mar 18 05:17:32 UTC 2011


Bruce wrote:
> On Thu, 17 Mar 2011 19:57:02 +0000, Harlan Stenn wrote:
> 
> > Please see http://support.ntp.org/bin/view/Dev/RefclockShmV2 
> [...]
> > I'm curious if we can support both POSIX and SVID SHM from the same
> > codebase, and use a flag bit or a mode to select which one is used.
> 
> OK, looked at it and the bug it references.  Comments:
> 
> 1. one code base is probably impractical (see separate response to Dave 
> Hart's post).

I think I've seen these and I still don't think it's a big deal.

> 2. What's needed to coordinate driver and shared memory client access is 
> a proper semaphore or mutex, not more modes to avoid doing the job 
> properly. For crying out loud, Dijkstra's semaphore paper is now ca. 46 
> years old:
> http://en.wikipedia.org/wiki/Semaphore_(programming)
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD123.html

OK.  I sure know about SVID semaphore mechanism.  The semaphore (or
mutex) operations *must* be nonblocking.

I do not know why folks have avoided this in the past. I'd be curious to
know why.

> 3. to get nanosecond timestamping on a non-proprietary platform implies 
> use of (POSIX) clock_gettime() or something like it, which uses (POSIX) 
> struct timespec.  If one has those, one likely also has POSIX shared 
> memory and POSIX mutexes and semaphores.  Mixing POSIX and SVID seems 
> like a bad idea; at some point, the SVID-specific stuff is going to go 
> the way of Lotus-1-2-3 (and I say that as a long time user of genuine 
> UNIX (Registered Trademark) System V).

I'm not worried about this.  When SVID dies, it dies.  It hasn't been
all that long that we deprecated K&R C compilers.

> 4. Assuming specific sizes for an integer is a really bad idea...
> "(64 bits making up the) clockTimeStamp* and receiveTimeStamp* fields"

I'm missing your point here.  We should only be using "generic" integral
types if we have reason to believe they are at least N bits wide.  For
anything else, we are using intNN types (for cases where we want exactly
NN bits).

H



More information about the questions mailing list