[ntp:questions] new driver development
nomail at example.com
Mon Mar 28 08:18:24 UTC 2011
Bruce Lilly <bruce.lilly at gmail.com> wrote:
> On Fri, 18 Mar 2011 03:16:38 +0000, Dave Hart wrote:
>> On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly <bruce.lilly at gmail.com>
>>> 4. Assuming specific sizes for an integer is a really bad idea... "(64
>>> bits making up the) clockTimeStamp* and receiveTimeStamp* fields"
>> Actually nailing down the sizes of objects is a really good idea when
>> sharing binary structures across separately-compiled programs. We
>> cannot presume the same compiler and options build ntpd and anything
>> that attempts to share memory with it. We need not (and should not)
>> worry about endianness for a shared memory contract, though.
>> Thanks for playing,
> 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.
For the scope of this driver, we can safely assume it isn't. Those
that have constructed a system where one processor is writing the
shared memory, and a different endianess processor is running the
ntpd, are probably able to write their own software to handle it.
More information about the questions