Re: [gpsd-dev] Last known 3.12 blocker solved

[Eric S. Raymond]

Hal Murray <address@hidden>:
> 
> > That's why I haven't yet done what I really want to do, which is rework the
> > allocation so *only* the root segments are created at startup, and only when
> > running as root.  The rest should be allocated only as actually needed by
> > PPS devices, which means in particular that none at all would be created
> > when gpsd is running in the test harness. 
> 
> I get confused by things like "actually needed by PPS devices".
> 
> ntpd and gpsd work fine with GPS devices that don't have PPS.

Right, I do have a tendency to forget that.
 
> What do you mean by "PPS device"?  Do you mean devices connected by hardware 
> that supports PPS? 

Yes, that is correct.

> I assume that ptys don't do that. 

That is also correct.

>    What about OSes that 
> don't even know about PPS?  What about Linux systems that don't have the PPS 
> modules loaded?

If you're telling me non-PPS GPSes feeding NTP is a real use case, then 
maybe preallocating those segments makes sense after all.

> > I just got rid of the InUse array, though.  A nearly trivial change that
> > will save us doing an object file compatibility break later, and easy to
> > live-test.  You should smoke-test with head to make sure it works for you,
> > too. 
> 
> I assume you moved the flag into SHM.  I don't see how to do that cleanly.

There's an array of ints at the end of the structure called 'dummy' that's
clearly padding and/or for future expansion.  I put the flag there.
 
> Who initializes that flag?  Will it get left set if gpsd crashes or gets 
> killed?

Starts at zero when the segment is created.  It's set at device-open time,
cleared at device-free time.  It will get cleared on any signal but a -9.

> How does making a change now solve an object file compatibility issue?  Who 
> is being (in)compatibile with what?

We just did a major API bump for other reasons.  Downstream dislikes those
but it's necessary every 2-3 years as the technical debt piles up.  By making
this change now, we slow the buildup of pressure to do another one. 

> [from the SHM code thread]
> > I think the logic we already use would work. Right now it guarantees no
> > collisions for multiple GPS devices managed by gpsd by walking the shmTime
> > array and allocating the first slot for which the corresponding shmTimeInuse
> > bool is false.  With the bool in the shmTime structure the same logic would
> > work for *all* refclocks. 
> 
> I think I've figured out what you mean by "work for *all* refclocks".  You 
> mean if some other package is also trying to pass info to ntpd via SHM.

Yes.
 
> Does that case exist currently?  If so, how does it work?  I don't remember 
> seeing any discussion along those lines.

I don't know.  I assumed that it was a relatively important case simply because
NTP supports so many segments.  Surely it wasn't expected that one refclock was
going to feed 248 segments, or even 6?

> My vote is to NOT do your trivial change now, but include the allocation 
> problem as part of a general SHM cleanup.

It's done and tested.  One of the advantages of doing the small change
now is that I think it decreases the odds that the general API cleanup
will produce strong pressure for an incompatible structure change.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>