[ntp:questions] new driver development

Bruce Lilly bruce.lilly at gmail.com
Fri Mar 18 02:28:43 UTC 2011

On Thu, 17 Mar 2011 22:05:29 +0000, Harlan Stenn wrote:

[quoting "unruh"]
>> I suspect what he had in mind was to make an entirely new driver, with
>> a new number, which was the posix shm driver, and hope that eventually
>> the old one would decay from lack of use.

That's about right.

>> Of course that
>> leads to driver proliferation ( do we really want a world where there
>> are 16000 drivers?

I'm proposing to add one (1) to address specific issues and which would 
be capable of being interfaced to a variety of hardware (I currently 
interface to a GPS/PPS device and a couple of WWVB radio clocks), not 

>>  Actually more than 255 would be problematic) since
>> drivers are never dropped ( someone might be using them) as can be seen
>> from some of the drivers which are in there and which I suspect at most
>> one person in the world uses.

23, 24, 25 seem to be unused...

at REFCLOCK_MAX = 44, I compute at most 18% of the capacity used.  Hardly 
a cause for alarm.
> I read this and it only adds to my belief that we need a "refclock
> definition language" and a means to easily customize them.  From what I
> can see, this solution elegantly solves a fairly encompassing "problem
> space".
> Just so it's handy still:
>  http://support.ntp.org/bin/view/Dev/
>  http://support.ntp.org/bin/view/Dev/LoadableRefclockDrivers

Most of the existing ntp drivers support some way to interface specific 
hardware to the ntp core daemon code.  Shared memory driver(s) are an 
exception; they represent a sort of middle ground where some client 
interfaces to the hardware, and communicates via shared memory to the 
driver which passes the information to the ntp core code. As distinct 
from the hardware-specific drivers which are compiled into the ntpd 
executable, hardware interfaces using shared memory are separate programs 
(like gpsd). Given a suitable shared memory (or similar technology) 
driver, there should in theory be no need for any separate hardware-
specific ntpd drivers; hardware interfaces could simply be shared memory 
(or similar technology) clients (a la gpsd).

Note however:
1. the transition from the current situation isn't going to take place

2. A unit count of 4 is likely to be insufficient if there's only one (or 
a very few) driver(s) for hardware devices to connect via; in that 
respect, the existing SHM driver goes into obfuscation mode [well, some 
might say that 0x4e545030 is already obfuscated :-)] above unit 9, 
whereas my proposal
  a. easily handles the IPv4-derived ntp maximum of 256 units
  b. could easily handle up to whatever the implementation has as an 
unsigned integer (more than 4 billion on 32-bit architectures)
  c. could theoretically handle more than a google squared units using 
only decimal numbers for the unit naming given the POSIX shared memory 
namespace name size of 255+  [i.e. "ample namespace size for ridiculously 
huge numbers of units w/o obfuscation"]

3. Interfacing via shared memory opens a means for injecting false timing 
information that is distinct from what exists with hardware-specific 
drivers [or with shared libraries (etc.)].  That hasn't been adequately 
considered either in the existing SHM driver or in my proposed code; some 
sort of authentication scheme workable via shared memory (or similar 
technologies) might be a suitable research project.

4. On a positive note, going this route means [eventually] smaller ntpd 
code with a fairly clean separation between ntpd as a kernel timekeeping 
manager and separate programs (e.g. gpsd-like) for interfacing to 
hardware timing devices.

More information about the questions mailing list