[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
--
- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the hackers
mailing list