gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] SHM refclock improvements


From: Gary E. Miller
Subject: Re: [gpsd-dev] SHM refclock improvements
Date: Tue, 28 Aug 2012 16:31:49 -0700

Yo Harlan!

On Tue, 28 Aug 2012 16:08:27 -0700
Harlan Stenn <address@hidden> wrote:

> > Yes, and trying to get gcc to not optimize out, and properly fence,
> > the SHM access is a bitch.
> 
> I don't know if 'volatile' will help there or not.

We have tried that, but still run into corner cases.

> I used to do a *lot* of work with SYSVIPC, including SHM, SEM, and the
> message queue stuff.  Yeah, it's miserable and it doesn't get any
> easier as compilers "go deeper" or as stages along the way sometimes
> aren't done right.

Yup.

> > Threads are so controversial and non-portable I would prefer not to
> > touch that idea.
> 
> I'm in that same camp too, and I'm hearing from folks I trust that
> things are much better now.

Better, but I was just looking at the new ARM locking, ugh.

No need to grasb any code from the chronyc project, I just refreshed
my memory on how it works and it is pretty trivial.

Now that I look at the code they call it their SOCK interface.  The
chronyd side is in their file: refclock_sock.c.

Their whole driver source is only 132 lines and looks pretty simple.
OTOH, if you are being cautious about the license then maybe you should
not look at it. :-)

All they really do is:
        open the socket and bind to it
        a  main loop sitting in a select() waiting for input.
        If there is input they read a structure from it.

The structure mostly has the time stamp of the measurement and the
measured offset.  All the hard part of threading, volatile, etc.
is left where it belongs, in the kernel.


> NTP would need non-GPL'd code, and if this was to happen for 4.2.8 it
> would need to be non-blocking.  It would also have to happen very
> soon.

Since the gpsd support is already in production use, only the ntpd side
would need to be done and it would be simple.  I would be happy to assist
anyone that is comfy with adding ntpd refclocks.  Since it would be a
new refclock it would not need to be perfect as it would not break
any existing implementation.



RGDS
GARY
---------------------------------------------------------------------------
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]