[ntp:questions] new driver development

Dave Hart davehart at gmail.com
Mon Mar 28 05:08:23 UTC 2011

On Mon, Mar 28, 2011 at 02:40 UTC, Bruce Lilly <bruce.lilly at gmail.com> wrote:
> On Fri, 18 Mar 2011 03:16:38 +0000, Dave Hart wrote:
> > We need not (and should not)
> > worry about endianness for a shared memory contract, though.
> Endianness (and more generally byte order) are of concern for precisely
> the same reasons.  Perhaps you are unfamiliar with:
> http://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware

I've never personally been exposed to a system which switches
endianness at runtime, though it was pointed out by Terje in the
recent gpsd-dev@/hackers@ thread on shared memory layout.  I was aware
of processors which could operate in either mode selected at boot
time, having been in the Windows NT group which was an early motivator
for such capability in MIPS and PowerPC processors.

I'm not convinced this is going to be an issue for ntpd's
refclock_shm, though.  Why isn't the answer to the problem "it hurts
when I run opposite-endian to the default and share memory with
programs using the default" simply "stop doing that" ?  Are there any
operating systems which would make this particularly easy, exposing,
say two different-endian faces to legacy apps vs. current, but
allowing them to share memory?

Dave Hart

More information about the questions mailing list