Gary (on users) said:
> Sure feels like a droproot permission problem.
It's a feature, not a bug. ;(
If gpsd runs first, it needs to set things up so user ntpd can write to the
SHM it creates. ntpd would have the same problem if gpsd had an
early-droproot.
Can we fix this by putting users
On Wed, Apr 10, 2019, 3:01 PM Hal Murray via devel wrote:
>
> g...@rellim.com said:
> > I would go further and say that order matters not at all. What matters
> is to
> > start both as root. Depending on whether I am working on gpsd of ntpd I
> will
> > just keep restarting the one I am working
Yo Hal!
On Wed, 10 Apr 2019 15:01:26 -0700
Hal Murray via devel wrote:
> g...@rellim.com said:
> > I would go further and say that order matters not at all. What
> > matters is to start both as root. Depending on whether I am
> > working on gpsd of ntpd I will just keep restarting the one I am
g...@rellim.com said:
> I would go further and say that order matters not at all. What matters is to
> start both as root. Depending on whether I am working on gpsd of ntpd I will
> just keep restarting the one I am working on. Never an issue.
How do you configure ntpsec?
I think the order
Hal Murray :
> Or maybe a json designed for ntpd rather than gpsd.
I like that plan. (As long as there's a receipt-timestamp field
so the client can compensate for parse latency.) All the issues that
make JSON a good choice for GPSD bear on this, too, IMO.
--
http://www.catb.org/
> I don't think it can be made bakward-compatible with the existing one,
> though. Which means we might as well write a new triver onforming to the
> POSIX shared-memory interface.
I'd be happy to make a new driver and use POSIX. We could call it SHM2, or
SHMP, or ...
The real question is sho
Hal Murray :
> > I'm not clear what you mean by making it read-only. Can you explain?
>
> The current stuff has the sender set a ready bit and the receiver turn it
> off. That only works if you have one receiver. Things like gpsmon can't run
> while it is also being used by ntpd.
>
> You ca
Yo Hal!
On Fri, 06 May 2016 17:47:07 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > Works for me, the folks worried about socket jitter need
> > convincing. I do not think socket jitter is a problem.
>
> Who is worried about socket jitter?
You are, at least for SHM jitter, see below.
g...@rellim.com said:
> Works for me, the folks worried about socket jitter need convincing. I do
> not think socket jitter is a problem.
Who is worried about socket jitter?
SHM works by polling. That's horrible delay and there is no way to correct
for it.
--
These are my opinions. I ha
Ok, thanks!
On Fri, May 6, 2016, 5:10 PM Gary E. Miller wrote:
> Yo Mark!
>
> On Sat, 07 May 2016 00:01:00 +
> Mark Atwood wrote:
>
> > absolutke not to json over shm.
> >
> > once you have done that, with the needed mutexes and ring pointers,
> > you have just literally reimplemented unix
Yo Mark!
On Sat, 07 May 2016 00:01:00 +
Mark Atwood wrote:
> absolutke not to json over shm.
>
> once you have done that, with the needed mutexes and ring pointers,
> you have just literally reimplemented unix domain socket in user
> space, less safely
Works for me, the folks worried about
absolutke not to json over shm.
once you have done that, with the needed mutexes and ring pointers, you
have just literally reimplemented unix domain socket in user space, less
safely
On Fri, May 6, 2016, 2:10 PM Gary E. Miller wrote:
> Yo Hal!
>
> On Fri, 06 May 2016 13:56:43 -0700
> Hal Murra
Yo Hal!
On Fri, 06 May 2016 13:56:43 -0700
Hal Murray wrote:
> > Are we presently using the old one? Where is documentation for the
> > new one?
>
> Do the old and new SHM schemes share the same name space? If gpsd
> uses old, can a ntpd using new talk to it?
No, fundamentally incompatible
13 matches
Mail list logo
