[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] SHM code
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] SHM code |
Date: |
Sun, 15 Feb 2015 06:03:44 -0500 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Harlan Stenn <address@hidden>:
> > Please include a version number as first field so future report
> > sources can be written with forward portability.
>
> Yeah, I always wanted that. The problem with doing it now is it's
> backward incompatible.
I understand the problem. My belief about this is that when you know you're
going to have to break compatibility, do it *as soon as you can* to get the
transition pain overwith as fast as possible.
One way to work around the problem would be to ensure that the old and new
structure have different sizes, then tell people to check the size of the
segment using shmctl(IPC_STAT, ...) and dispatch appropriately. That way
a driver on either side of the connection can autoconfigure itself.
So, with
struct shmTime {
int mode; /* 0 - if valid set
* use values,
* clear valid
* 1 - if valid set
* if count before and after read of values is equal,
* use values
* clear valid
*/
int count;
time_t clockTimeStampSec;
int clockTimeStampUSec;
time_t receiveTimeStampSec;
int receiveTimeStampUSec;
int leap;
int precision;
int nsamples;
int valid;
unsigned clockTimeStampNSec;
unsigned receiveTimeStampNSec;
int dummy[8];
};
struct shmTimeExt {
int32_t version;
bool mode; /* 0 - if valid set
* use values,
* clear valid
* 1 - if valid set
* if count before and after read of values is equal,
* use values
* clear valid
*/
int32_t count;
time_t clockTimeStampSec;
int32_t clockTimeStampUSec;
time_t receiveTimeStampSec;
int32_t receiveTimeStampUSec;
int32_t leap;
int32_t precision;
int32_t nsamples;
int32_t valid;
uint32_t clockTimeStampNSec;
uint32_t receiveTimeStampNSec;
uint32_t dummy[8];
};
you'd be pretty much guaranteed that sizeof(struct shmTime) !=
sizeof(struct shmTimeExt). (You probably need to replace time_t with
a fixed-size type, too.)
> > The dummy field is useful; a segment-in-use flag can live there (though
> > the GPSD implementation does not currently do this). Some field
> > space reserved for use as client flags would be nice.
>
> How does one decide who is using which areas for client flags? The
> answer to this may become more apparent after I wake up.
The point is only that NTP never touches it; it's up to the refclocks
to ensure they don't step on each other. Often there will only be one
refclock, so no issue.
Mainly, as I said, this would be nice for a segment-in-use flag. You
want this to be in shared space so all refclocks can see it.
An alternative would be to have a specific 'in_use' field documented
for this use.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>