Gary E. Miller <g...@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>
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
