[ntp:questions] new driver development
bruce.lilly at gmail.com
Fri Apr 1 22:33:43 UTC 2011
On Wed, 30 Mar 2011 07:15:16 +0200, Terje Mathisen wrote:
> 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.)
I suspect that there may be some compilers for 32-bit platforms
that won't know what to do with a 64-bit field (declared as such).
The approach I took was to use a local (i.e. non-shared) union of 4
chars and a 32-bit int, setting the 4 chars to known values and
converting to host order with ntohl. That result is then put into
shared memory. Doing that for both processes allows each to detect an
incompatibility with the other (with shared memory for each process'
word size/endianness data). In retrospect, precautions would probably
have to be taken to ensure that the union was in the same page (or at
least a page with the same endianness) as the shared memory. Prior to
shared memory use for transfer, the union itself could be in shared
> 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.
I don't expect that endianness would change during process execution,
so initializing one time should suffice. In any case, I wouldn't
expect a performance issue.
> Bruce, I assume you follow both the gpsd and ntp-hackers mailing lists?
No, though I have seen a few messages in my inbox as a result of earlier
postings here ("here" being Usenet group comp.protocols.time.ntp).
More information about the questions