Anatomy of gpsd (and other linux driver/daemon combos)

So, it being Halloween I'm going to keep this weeks log short, but hopefully enlightening. For work, I recently had to do some debugging for a gps module that is connected over serial bus. There is a common, general-use daemon for gps aptly called gpsd (gps-daemon) that is commonly included in the linux kernel. Debugging this for specialized devices and use-cases, however, may not always be straightforward. So I hope to give you all a quick primer on how the gpsd stack (and a serial device stack) works in linux. When a device is connected, it is registered under your serial bus as a device, and can be seen with lsusb.

Udev (usually in /etc/udev) will need rules definded for how to interface or use such devices. For something like this, it would identify the device, and map the serial port (usually /dev/ttyXXXX) to a more specific name, such as /dev/gps0 and enumerate them from there. This is because we usually can't force each device to get a specific number in the autogenerated /dev/ttyXXXX and it is actually more reliable to symbolically link the new device to one we expect. If you're curious how some of them work currently, ls -la /dev will show you how the links are pointed around! From there, its a matter of digging into the logs (usually under /var/log/...) and making sure configuration is happening as expected. At this point, the device should be functionally mapped in.

You can use a serial terminal like 'picocom' or 'PuTTy' to target that port with a given baud rate (transfer rate) and see data! Now, any service (daemon) should be able to find and interface with this device! gpsd, in particular, will get telematics data for doing things such as updating system time, location, etc!

This, in essence, is how linux handles peripherals in the serial bus (USB). A device is connected, identifies itself, and starts talking. In the kernel, a udev "rule" that is predefined tells the system what to do with the new device based on manufacturing data that is sent over during the "identification" phase earlier. After that, system services and applications are able to reliably find and interface with these devices for whatever purpose they deem.

Thought it apt to bring up kernel-level and driver-level linux on Halloween since most of us have borderline traumatic experiences in the bowels of linux. Happy Halloween!

Up next:

• Going to hit that "how I use git" note from last week