gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Updated docs on NTP segment management


From: Hal Murray
Subject: Re: [gpsd-dev] Updated docs on NTP segment management
Date: Tue, 17 Feb 2015 23:26:02 -0800

> I thought that there was a time when the two sides did some sort of
> "handshake" thru the SHM segment, and that was apparently useful to let each
> side know the other side was paying attention. 

The current SHM stuff requires read/write by ntpd.

I think that making the client side of SHM read only is enough of a change 
that I've been assuming we would make a new interface.  It might be possible 
to make it somewhat backwards compatible, but that would be more in name than 
spirit.


> I can see the bit of danger if the segment is 666, and part of me wonders

Yes, the current setup is a security risk if you have more than one GPS 
device via gpsd/SHM.

        shmid=shmget (0x4e545030 + unit, sizeof (struct shmTime),
                      IPC_CREAT | ((unit < 2) ? 0600 : 0666));

--------

For the record, here is a recipe for a SHM handshake where the client can be 
read only...

(I think I said something close to this in a message months ago.  I think 
Eric said he invented a similar scheme which is used internally to gpsd 
someplace.)


It takes 2 counters.  Call them X and Y.

The writer bumps X, updates the data, then copies the new X to Y.

The reader grabs Y, grabs the data, then grabs X.  If X and Y differ, the 
data was being updated.  The reader has to compare Y with the previous value 
to ignore stale samples.

It's important that the reader and writer operate on X and Y in the opposite 
order.

SHM gets initialized to 0.  For initialization, the writer doesn't have to 
write anything.  The reader has to ignore the first sample if one is ready.


-- 
These are my opinions.  I hate spam.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]