[ntp:questions] new driver development
"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?
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