Re: [gpsd-dev] Fw: [gpsd-commit-watch] [SCM] GPSD branch, master, updated. release-3.11-483-gd3521ce

[Gary E. Miller]

Yo Eric!

On Sun, 15 Feb 2015 22:34:57 -0500
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > Yo Eric!
> > 
> > commit d3521ce59ba8065ca6e65f95787fcb7d6b0ac60d
> > 
> >     Simplify NTP SHM segment creation.
> >     
> > + * We use dummy[0] as an in-use flag, so segments can be released
> > and
> > + * reallocated from holes in the sequence.
> > 
> > Is this a good idea?  Not exactly like we are in control of the 
> > canonical use for that byte.
> 
> I look at it this way.  The dummy field is a trailing pad that's never
> been used.

Wrong, pieces have been taken out of dymmy[] at least once.

>  We know the structure is about to be redesigned; probably
> there will still be a dummy member, in which case we win.

Or parts of dummy get used, in which case we lose.

>  If there
> isn't, compilation will break noisily - but that was likely to 
> happen anyway.

It did not happen for the last change...

> > And given the file permissions will likely change soon too, maybe 
> > best to negotitate this with the ntpd guys?
> 
> I'm sure we're going to have to rework the ntpshm.c code anyway if
> they do anything nontrivial (I made my requests to Harlan last
> night).  So this is actually a low-risk time to experiment.

gpsd and ntpd binaries seem to last forever.  Not good to make 
a change now, of questionable usefulness, that precludes some options
for the new SHM structure.

Especially doing so AFTER gpsd feature freeze!!

Also, I have not responded to the SHM thread yet, but I see little
reason to do any changes that will not fit in the existing dummmy[] 
spaec.  That would be very preferable to forward/backward compatibility.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588