[ntp:hackers] [Gpsd-dev] Possible shm problem: Structure alignment?

Terje Mathisen terje at tmsw.no
Fri Mar 25 20:56:04 UTC 2011

Gary E. Miller wrote:
> On Fri, 25 Mar 2011, Terje Mathisen wrote:
>>> That is what ntpd tells us to do.  You need to get them to fix it
>>> and we will follow.
>> OK, I'll note this as a bug.
> Not a gpsd bug, an ntpd bug.  If fopen() where bad you would complain to
> the libc people, same applies here.

Oh, absolutely: This is a broken ntpd driver interface, we try to fix 
them without having to define any new driver definitions.

New modes for existing drivers is OK though.
>> Any fix _will_ break the current interface and require simultaneous updates on
>> both programs.
> Correct.  So it is what it is, until a new ntpd interface appears.  One
> that supports nSec time corrections I hope.

I agree, this doesn't change the interface memory layout though: We just 
use 30 instead of 20 of the 32 bits for the fractional seconds.
>> I suggest we work out all the details, then define a new 'mode' value to
>> indicate the new layout/interface definition: This way an old ntpd won't try
>> to interpret the new layout and mess it all up quite badly.
> If 'we' is the folks on ntpd hackers, yes.  The 'we' at gpsd just use
> the interfaces made available to us.

OK, there is already an attempt underway (started by Håkan from Sweden) 
to define a new (POSIX?) shm interface with ns support, merging that 
work with this effort to get a much more portable/stable interface would 
be good.

Seems like another case of 'rough consensus, working code', i.e. we just 
need to write and test the required code on both sides.


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

More information about the hackers mailing list