Discussion of porting to weird architectures.

1 files changed, 21 insertions, 0 deletions

diff --git a/HACKING b/HACKING
index b4a1484b..1feadd32 100644
--- a/HACKING
+++ b/HACKING
@@ -130,6 +130,27 @@ daemon to client library -- and to estimate the portion of the latency
 induced by serial transmit time.  The gpsprof script creates latency
 plots using gnuplot(1).  It can also report the raw data.
 
+** Porting to weird machines: endianness, type width, and signedness issues.
+
+The gpsd code is well-tested on 32- and 64-bit IA chips, also on PPCs.
+Thus, it's known to work on mainstream chips of either 32 or 64 bits
+and either big-endian or little-endian representation with IEE754
+floating point.
+
+Handling of NMEA devices should not be sensitive to the machine's
+internal numeric representations, However, because the binary-protocol
+drivers have to mine bytes out of the incoming packets and mung them
+into fixed-width integer quantities, there could potentially be issues
+on weird machines.  The regression test should spot these.
+
+If you are porting to a true 16-bit machine, or something else with
+an unusual set of data type widths, take a look at bits.h.  We've
+tried to collect all the architecture dependencies here.  If splint
+gives you warnings, it is possible you may need to adjust the -D
+directives in .splintrc that are used to define away fixed-width typedefs.
+
+(No, we don't know why splint doesn't handle these natively.)
+
 ** Architecture and how to hack it
 
 gpsd is not a complicated piece of code.  Essentially, it spins in a loop