[ntp:questions] new driver development

David L. Mills mills at udel.edu
Thu Mar 17 14:13:24 UTC 2011


Bruce,

I take it your driver will replace or modify an existing driver, right? 
Adding a new driver to the current population of over 40 drivers is  not 
a practical course.

Dave

Bruce Lilly wrote:

>I'm preparing a POSIX shared memory driver (PSHM) for ntp to address a
>few issues that exist with the present SHM driver.  In no particular
>order, these are:
>
> o POSIX (not SVID) shared memory
>
>   -- POSIX shared memory namespace rather than hexadecimal constant
>   -- avoids 0x4e545030 [...] Big units will give non-ascii
>   -- provides ample namespace size for ridiculously huge numbers of
>      units w/o obfuscation
>
> o nanoseconds, not microseconds
>
>   -- resolution compatible with bulk of the ntp reference
>      implementation
>   -- using POSIX struct timespec
>   -- client compatibility with POSIX clock_gettime()
>
> o per-unit configurable source type (a.k.a. class)
>
>   -- unlike present SHM driver, which treats all units as identical
>      and unconfigurable
>   -- currently UHF; wrong for everything else
>   -- was TELEPHONE; wrong for everything else
>
> o per-unit PPS flag
>
>   -- permits shared memory PPS drivers
>
> o POSIX-comforming code
>
>   -- no attempt to work around buggy (non-POSIX-conforming) systems!
>
> o separate header file to simplify client code
>
>   -- shared memory structure clearly defined and well-documented
>
> o source code/header version strings for use by what(1) or ident(1)
>
>   -- for facilitation of bug reporting, version verification, daemon-
>      client campatibility checks
>
> o client/driver run-time implementation/compatibility tests
>
>   -- integer and pointer sizes
>   -- endianness
>
> o no dead code
>
>   -- e.g. SHM driver "nsamples"-related cruft
>
> o provision in shared memory to specify (variable part of) clockstats
>   output
>
>   -- client can control clockstats format and content (and frequency
>      of logging)
>   -- can be different for each unit
>
> o POSIX mutex for synchronized access to shared memory for updates
>
>   -- obviates mode 0 / mode 1 / OLDWAY
>
>
>Comments and suggestions are welcome.
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>  
>




More information about the questions mailing list