[ntp:questions] new driver development
martin.burnicki at meinberg.de
Fri Mar 18 09:16:52 UTC 2011
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Bruce Lilly wrote:
>> 4. Assuming specific sizes for an integer is a really bad idea...
>> "(64 bits making up the) clockTimeStamp* and receiveTimeStamp* fields"
> Bruce, I tend to agree with your wish for totally separate drivers, but
> it is a fact of live around here that it is far, far simpler to get
> permission to add an extra mode to an existing driver.
Of course we should not want to add a new (type of) driver for every new
refclock device which can easily be handled by (slightly modified) existing
However, a SHM driver is somewhat generic, i.e. it can be used for a number
of backend drivers which feed timestamps into it, so maybe it's worth to
spend a single new driver number for this.
> I.e. using a flag1 value on the existing SHM driver to indicate that
> your version should be used instead is just another way to specify how
> ntp.conf should be parsed.
On the other hand, for folks who are not too familiar with NTP it would be
easier to understand a single line reading
server 127.127.41.0 # POSIX SHM
than a fudged driver entry like
server 127.127.28.0 # SHM driver
fudge 127.127.28.0 flag1 1 # enable POSIX mode
I'm not familiar with POSIX SHM details, but from the point of view from SHM
feeders (like gpsd) it would also be easier to say "you can use this with
ntpd's driver 41" than to say "you can use this with driver 28, but you
need to fudge flag1 to 1".
The fudge commands are usefull to tweak some parameters of how the driver
works, interprets specific data fields, etc., but in cas ot the SHM driver
this would toggle between 2 totally different mechanisms to exchange data,
so a new type would IMO be appropriate here.
> OTOH, re. fixed sizes for timestamp fields: This is NOT just a "good
> idea", it is an absolute requirement for all (binary) network-based
> On the gripping hand, until quite recently the ntp timestamp processing
> code used 32-bit operations only, even on platforms that did support
> 64-bit ints.
> The key issue is that all network protocols have code to take
> individual bytes in network order and merge/combine them into whatever
> the best local integer size happens to be.
Are we going to feed SHM directly via a network protocol? If not then it
should be fine to use generic types to define the data structures.
I think even if you use different compilers to build binaries for a given
target/architecture, the size of e.g. a "long" should always be the same
for those binaries for the given target. Otherwise there were e.g. huge
problems to use shared libraries built with one compiler from an
application built with a different compiler.
If timestamps are exchanged over a network then there will be a frontend
application which sends and receives packets and converts the datra fields
from to the SHM structure accordingly, care about endianess, etc.
More information about the questions