Re: [gpsd-dev] (no subject)

[Gary E. Miller]

Yo juergen!

On Fri, 16 Jan 2015 21:00:29 +0100
juergen perlinger <address@hidden> wrote:

> > without thinking about it.  If the intent is to enforce a newer and
> > better security model then this should at least be noted in an
> > upgrade doc under Incompatible Changes.
> I just tried it with the current stable version. (Which is ntpd 
> 4.2.8p1-beta5). I made sure the SHMs were 'ipcrm'd before I started.

[...]

> ---> works <---

Yes, but...
 
> My NTP.CONF contains
[...]
> server 127.127.28.2 mode 1 noselect
                      ^^^^^^

You needed to change your ntp.conf to work.  The proper test for upward
compatibility it to take an old ntp.conf, update to the new ntpd and
then run your tests.  It will fail.

> >> And yes, you might have to change the SHM clock config for units
> >> >= 2 to get the old behavior,
> > Make that WILL.  If this stands it needs to be red flagged in the
> > doc.
> Accepted.

So, we agree it is a bug.  As Linus Torvalds rants on regularly, breaking
compatibility is unacceptable.

> As a suggestion:
>      mode bit 1: permissions o+rw
>      mode bit 2: permissions g+rw
>      mode bit 3: when set, owned by runtime user/group,
>                            when cleared, owned by root.root (or maybe 
> root.wheel)


AND no change to existing pracctive when mode is zero or empty.

>      mode bit 3: when set, owned by runtime user/group,
>                            when cleared, owned by root.root (or maybe 
> root.wheel)

Not all Linux have wheel, so root:root.

> I would still 'shmget(x,y,IPC_CREAT)' as root to open/create the 
> segment, and I might use 'shmctl()' to change the 
> owner/group/permissions as requested.

I only care about the public interface, but that looks fair at first
glance.
 
> > <snip>
> > F*ck windows. :-) Windows is already a special case, it can stay 
> > 'special'. 
> 
> It will always be special. But Id don't think it can be ignored. The 
> UN*X world tried that approach in the 1990ies, and we still suffer
> from it ;-)

I'll leave that to those that care.

> > <snip>
> > Actually, the precision is now ine as it is nanoSec possible. As
> > for the rest I like how chronyd does it with sockets. 
> The nanosec precision is supported.

So, we agree on the nanoSec, what about the sockets (long term)?
 
> <snip>
> >> I maintain the gpsd SHM code, does any project other than gpsd
> >> really use the SHM code?  Let's talk.
> 
> Not the standard one. I cooked up something very special and it's
> used in a SCADA system.

Yeah, easy to forget about how the rest of the world is doing things when
you are customizing.

> > BTW, ntpd should just kill off the new JSON driver, it makes
> > assumptions that make it unuseable for timekeeping.
> 
> You might elaborate a bit. Because it works quite well for me:

The gpsd PPS code runs in a its own thread.  That thread does not
reliably report to the main thread that runs the JSON.  It could work
on a single CPU system, but will fail strangely on multi-core systems.
It certainly fails for me, and the first time I checked that code it was
reporting a time value unrelated to any real PPS signal.  It looked
great, but was imaginary.

Someone patched in the link between the threads without properly locking
things, or doing the math properly.  Since it looks like people are
using an undocumented, untested, and known broken experimental feature
I'll need to poke at it and make it work.

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