Hacker's Guide to gpsdThis is not a complicated piece of code.  Essentially, it spins in a loop polling for input from one of three sources:1) A client making requests over a TCP/IP port.2) The GPS, connected via serial or USB device.3) A DGPS server issuing periodic differential-GPS updates.The daemon only connects to the GPS when clients are connected to it.Otherwise the GPS device is closed and the daemon is quiescent, butretains fix and timestamp data from the last active period.  This isbetter functional design than starting the daemon from a hotplugscript would be; that would lose the old data, leaving no fix at allavailable if the GPS were momentarily unplugged.All writes to client sockets go through throttled_write().This code addresses two cases.  First, client has dropped the connection.Second, client is connected but not picking up data and our buffers arebacking up.  If we let this continue, the write buffers will fill and the effect will be denial-of-service to clients that are better behaved.Our strategy is brutally simple and takes advantage of the fact thatGPS data has a short shelf life.  If the client doesn't pick it up within a few minutes, it's probably not useful to that client.  So ifdata is backing up to a client, drop that client.  That's why we setthe client socket to nonblocking.GPS input updates an internal data structure which has slots in it forall the data you can get from a GPS.  Client commands mine thatstructure and ship reports up the socket to the client.  DGPS data ispassed through, raw, to the GPS.The program supports multiple GPS types.  All are represented bydriver method tables; the main loop knows nothing about the drivermethods except when to call them.  At any given time one driver isactive; by default it's the NMEA one.  Each driver may have a trigger string that the NMEA interpreterwatches for.  When that string is recognized at the start of a line, the interpreter switches to its driver.  The new driver initializer method is called immediately.  If there is no trigger stringthe initializer method is called unconditionally each time the deviceis opened.The trickiest part of the code is the handling of input sources in gpsd.c itself.  It had to tolerate clients connecting and disconnecting at randomtimes, and the GPS being unplugged and replugged, without leaking file descriptors; also arrange for the GPS to be open when and only when clients are active.The function is_input_waiting() is not strictly necessary for the mostimportant use of the low-level interface, which is when it gets calledfrom the daemon mainline.  In that context, FD_ISSET() on the elementof the file-descriptor set representing the GPS would tell us if therewere input waiting.  The explicit test is there for other programsthat might call gps_poll() without such a guarantee.That's about all there is to it.If you're looking for things to hack on, first see the TODO file.Then, there is some C code in the contrib/ directory that has somepotentially useful techniques in it.  Picking a good one to integrateinto gpsd might be a useful thing.For debugging purposes, it may be helpful to configure with --disable-shared.This turns off all the shared-library crud, making it somewhat easier touse gdb.