Yo Eric! On Thu, 20 Oct 2016 07:11:20 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote:
> Gary E. Miller <g...@rellim.com>:
> > Oh, please not! That is one of the big problems in the existing
> > driver. Way too compiler, CPU and OS dependent. Plus not
> > extensible. The exsting C struct has been nothing but problems.
> > Maybe you don't buy into JSON, but the C struct is a non-starter.
>
> Way too compiler, CPU and OS dependent?
>
> Dependent on lots of things, but important variables (endianness,
> word length, CPU, OS) are coupled on either side because the sending
> and receiving processes are running in the same memory space on the
> same hardware.
You would think so, but years of expericne with gpsd and ntpd show
otherwise. This problem rears its ugly head several times a year.
> Plus not extensible?
>
> As Hal points out, if you version-number the struct properly you can
> add fields at the end ad libitum.
IFF you do it right, AND chose a transport that can handle varying
lengths. Traditional SHM can not do that. The current NTP SHM can
not do that.
But that still makes it a PITA to debug. Just look at your recent
experience with pyntpq. You realized how much easier the ascii
query was to write than the binary one. QED
> The existing C struct has been nothing but problems? OK, list them
> for me. I'm not seeing it.
See my recent message to Hal, I stopped at 6, but coulda gone on...
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
pgpqNBRcK7Fs0.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
