[Top][All Lists]

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

Re: [gpsd-dev] PPS and privilege-dropping

From: Gary E. Miller
Subject: Re: [gpsd-dev] PPS and privilege-dropping
Date: Fri, 18 Oct 2013 10:57:57 -0700

Yo Eric!

On Fri, 18 Oct 2013 07:04:28 -0400
"Eric S. Raymond" <address@hidden> wrote:

> > Ugh.  That is seriously broken in more than one way.  It explains
> > some errors I have been seeing but had not tracked down.  Let's get
> > PPS so it builds again and then I will fix that too.  How about you
> > move that to ntpshm.c so it is obvious that it is a non-thread safe
> > function in a thread. Then I'll make sure it is one reporting the
> > right data and two doing it in a thread safe manner.
> I specifically *don't* want to move that code from where it is, for
> architectural-hygiene reasons.  Doing so would create a nasty cohesion
> and drag a reporting helper tied to JSON emission into code where it
> doesn't belong.

But that is the bug, you can not have a JSON emitter in the PPS thread!

By putting it in gpsd.c you give the misleading impression that this
function is called in the main thread, but it is not.

> At present, only gpsd uses ntpshm.c, but it would be wrong to assume
> that will always be the case.  In the future I might very well write a
> dedicated time-drift monitor that would watch PPS without needing to
> do any of gpsd's session management and socket-fu, and would never
> ship JSON.

OTOH, the PPS emitter can never be separated from ntpshm.c.  So 
might as well be in the same file.
> What should be thread-safed is not ship_pps_drift_message() itself,
> but the call to the pps_hook slot in the context structure.

Which calls ship_pps_drift_message() which is not thread safe.  So
you can protect it up a level if you want.

>  I
> created that so that the PPS handler would have a way to call out to
> reporting code without having to know or care exactly what it does.

But it fails at that because it is currently not thread safe.

> We must preserve that property.

We must fix the property.

> The content of the report is a different issue.  You have implied
> that the data in it is misleading; I want to know why you think that
> and, if required, fix it.  (See "representation of domain" below.)

It is not using the right time structures.  I'll fix it.

> I freely admit that I don't get it.  I know a lot of specific isolated
> things about time service, but they don't cohere for me into a whole
> that would permit me to set up and tune a time server and then
> diagnose problems.  Now I intend to get it, and in the process I
> intend to capture and document the time-nut way of thinking about
> those facts.

Good, let's keep at it.

> That's not enough by itself.  You and other time nuts have implicit
> knowledge, expressed in jargon like "chimers" which isn't actually
> defined anywhere (I googled to check).  We need to get that knowledge
> onto (virtual) paper.

Odd, I can't find a trvial reference to that either.  A chimer is just
an time source you are using.  Likely remote in some way.

> > BTW, there was an article on this years ago in Linux Journal that
> > was well written.  We should get a copy of that to look at.
> Was it one of these?

Nope, a little older.  I can't find it, so not wirth worrying about.

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

Attachment: signature.asc
Description: PGP signature

reply via email to

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