Proposal - drop the GPSD JSON driver

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> > What sort of problems are there with the current one?
> 
> Do we really need to go over this yet again?  These have been covered
> for years.
> 
> First, the structure needs to be polled, sometimes leading to long
> delayed and even missed samples.

This will be the case with any shared-memory driver that doesn't have a
wait semaphore.  Which means that a wait semaphore is a good idea, but is
orthogonal to the struct-vs.-JSON-question to put in the box.

You seem to have changed the subject from "the existing SHM sriver is bad" to
"any shared-memory driver would be bad".  Do you believe that?

> Second, a big one, the C structure is of loosely defined size and shape.
> Even on the same host you need to use the same compiler and word length
> for client and server.  For example, you can't compile the client as 32
> bit and the server as 64-bit.

No sale. You don't need to use the same compiler, just two compilers with
self-aligned padding.  If this weren't a safe assumption, NTP Classic would
have been changed to remove it decades ago.

(Note to self: Revise "The Lost Art of C Structure Packing" to reflect
the NTP field evidence that this has not been an issue since
approximately forever.)

Word-length mismatch between two programs built under the same OS never
happens, or close enough to never that I don't care.  Not willing to eat
more jitter to armor against that extremely remote contingency.

Have we on GPSD ever had an actual bug report due to these causes?  I know
the answer, and it's a big "no".

> Third, you pretty much need to reboot the server when you change the struct
> size as deleting the old SHM segment while running is problematic.

Not true, we have a recipe for handling this case without rebooting in
the GPSD Time Service HOWTO.

> Fourth, teaching people to debug with ipcs is a PITA.

True, but pretty minor stuff. Cases where you have to do that kind of
debugging are rare.

> Fifth, security is hopeless.  Client and server both need to run as
> root to be somewhat safe and only 2 SHM slots can do that.  After that
> the SHMs are wide open to anyone on the server to mess with.

I think you're being over-dramatic here.  Yes, there is a theoretical hole
here but no evidence that it's ever been exploited.  "Hopeless" would be
if there were a history of such attacks.

Is this a contingent problem with the way permissions are set
by the exiting driver?  If so, we can fix it in a new one.

> Sixth, so many of these problems are so hard to grasp that people
> get amnesia about them after on eday.
> 
> Seventh...  well.  I could go on but I need more espresso, and the following
> should be more than enough to show the current SHM needs killing off.
> Sadly that will take a decade, after the next good solution is
> implemented.

You seem to have mixed together at least three different categories of
objections.  One is to the existing SHM driver.  A second is to any
driver based on a shared-memory drop with structure passing.  A third
is to any shared-memory driver at all.  It would be helpful if you
separated these more cleanly.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161020/8d5f47e9/attachment.bin>