[ntp:questions] new driver development

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Wed Mar 30 05:15:16 UTC 2011


Bruce Lilly wrote:
> On Mon, 28 Mar 2011 08:18:24 +0000, Rob wrote:
>
>> Bruce Lilly<bruce.lilly at gmail.com>  wrote:
>>> Endianness (and more generally byte order) are of concern for precisely
>>> the same reasons.
>>
>> This is not relevant in the case of shared memory, as long as the memory
>> is not shared between processors of different endianess.
>
> Please reread the information regarding bi-endian hardware and note that
> some can be configured to switch endianness on a per-page basis.  That's
> with a single processor. Note also that the mapping of memory in
> different processes may be to different addresses (i.e. different pages).
>
> Given that there are two separate processes involved, I cannot safely
> assume that different endianness might never arise; it's certainly
> conceivable that the ntp side might be built big-endian (to simplify
> networking operations), while the other process might be little-endian
> (perhaps to more efficiently cope with hardware).

This is exactly the reason why the shm communication setup I am 
currently testing has a 64-bit marker as the first field:

(It is "GPSD-NTP" when viewed as a little-endian string.)

This is specifically to make it easy to detect any (unlikely but 
possible) per-process/per-page endian changes.

Since the current testing have shown that it works with 13 M 
updates/second, I feel quite safe that it will work fine for one or a 
couple of timestamp messages per second.

Bruce, I assume you follow both the gpsd and ntp-hackers mailing lists?

Terje
BTW, I really didn't realize that we had that many different driver 
numbers, even for different models of the same manufacturer's refclock!

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list