[ntp:questions] new driver development
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:
>> 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
> Just so it's handy still:
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).
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