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

[Hal Murray]

> 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.

What do you mean by "PPS device"?  Do you mean devices connected by hardware 
that supports PPS?  I assume that ptys don't do that.  What about OSes that 
don't even know about PPS?  What about Linux systems that don't have the PPS 
modules loaded?


> 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.

Who initializes that flag?  Will it get left set if gpsd crashes or gets 
killed?

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


[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.

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

If I wanted to write a package that would do that, I'd have it start with a 
big offset rather than 0.  Yes, it's a kludge.  Or hack the ntp SHM driver to 
have an option to use a different key.


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


-- 
These are my opinions.  I hate spam.