Week 9 — Networking, Devices, /dev, /sys, Interrupts, and GPIO

Overview

This week covers how a Linux machine talks to the network and to hardware. It consolidates the networking week with the devices/interrupts week because both are about the boundary between software and the outside world — packets arriving on a wire and electrical events arriving on a pin are the same problem at different layers, and both surface to user space through file-like interfaces and interrupts. You will go from networking tools down to socket programming (TCP and UDP), and from /dev//sys down to how interrupts and GPIO let hardware events reach software.

This is the most directly embedded-relevant week, and it connects tightly to Course 1’s robotics runtime (CAN, IMU, GPIO on the Jetson) and Course 6’s signal acquisition. By the end you can write a socket server/client, inspect devices through /sys, and explain how an interrupt turns a hardware event into a software handler.

Readings

HLW Ch. 9: network configuration. Extract: interfaces, IP, routing, and the network stack layers.
HLW Ch. 10: network applications and services. Extract: sockets, TCP vs UDP, and DNS.
HLW Ch. 3: devices, /dev, /sys, udev. Extract: how devices appear as files and how /sys exposes them.
ARM Ch. 20–21 and CA Ch. 9: input/output, exceptions, and interrupts. Extract: the interrupt mechanism and memory-mapped I/O.

Key Concepts

The network stack and sockets

The layered model (link → IP → transport → application) maps to the kernel’s stack; a socket is the user-space handle (a file descriptor, Week 7) into it. TCP gives a reliable, ordered, connection-oriented byte stream (handshake, sequence/ack, retransmission, congestion control; teardown is the four-way FIN/ACK with TIME_WAIT); UDP gives unreliable, connectionless datagrams — lower latency, no ordering guarantees. Choosing between them is a core systems decision (control vs telemetry, the CAN/robotics framing of Course 1).

Packet inspection

tcpdump/Wireshark show real packets on the wire — the clearest way to understand a protocol and debug network behavior. Seeing the TCP handshake and a UDP datagram concretely demystifies the abstractions.

Devices, /dev, and /sys

The kernel exposes devices as files in /dev (character/block devices) and their attributes/state in /sys (sysfs). udev manages device nodes as hardware appears. Reading/writing these files is how user space controls hardware without custom syscalls — including GPIO via the sysfs/chardev interface, the mechanism Course 1’s Jetson work uses.

Interrupts, memory-mapped I/O, and GPIO

Hardware signals the CPU via interrupts: the CPU suspends current work, vectors to a handler, services the device, and resumes. The two ISAs structure this differently: ARM64 uses an exception-vector table (the VBAR_EL1 base, with separate entries for sync/IRQ/FIQ/SError at each exception level), while x86-64 uses an Interrupt Descriptor Table (the IDT, 256 vectors indexed by interrupt number). Memory-mapped I/O — mapping device registers into the address space (Week 8) so ordinary loads/stores control hardware — is common to both and is the only device-access mechanism on ARM64; x86-64 additionally has a separate I/O-port space accessed with dedicated in/out instructions (a CISC legacy ARM never adopted). GPIO pins are the simplest MMIO case — read an input, drive an output, or trigger an interrupt on an edge — the foundation of embedded sensing/actuation (Course 1’s IMU/CAN, Course 6’s acquisition).

Theory Exercises

Contrast TCP and UDP across reliability, ordering, connection state, and latency; pick the right one for bulk transfer vs real-time telemetry.
Trace the TCP three-way handshake and four-way teardown; explain TIME_WAIT and why it exists.
Explain how a socket is a file descriptor and how read/write on it map to network I/O (Week 7).
Explain the interrupt lifecycle (signal → vector → handler → resume) and contrast polling vs interrupt-driven I/O.
Describe how GPIO and memory-mapped I/O let software read a sensor pin and drive an output; relate to Course 1’s embedded work.

Implementation

Write a TCP echo server/client and a UDP sender/receiver (labs/week09-networking-devices) using sockets; observe both with tcpdump. Inspect devices through /sys (e.g. read a sensor or battery attribute). On the Jetson/Pi, toggle a GPIO output and read an input, optionally using an edge interrupt — connecting to Course 1’s sensor/actuator work and Course 6’s acquisition.

Measurement / Inspection

Capture the TCP handshake and a UDP exchange with tcpdump and annotate the packets. Measure TCP vs UDP latency/throughput for small messages. Enumerate a device’s /sys attributes. Measure GPIO toggle rate and, if using interrupts, latency from edge to handler (polling vs interrupt comparison).

Expected baselines: the echo server handles concurrent clients; tcpdump shows the expected handshake/teardown; UDP has lower latency and no reliability for small messages; /sys exposes readable device state; GPIO toggles at a measurable rate, and interrupt-driven input has lower CPU cost than tight polling.

Connections

Sockets, devices, interrupts, and GPIO are exactly the mechanisms Course 1’s Jetson runtime uses for CAN, IMU, and actuators, and that Course 6’s data acquisition rides on. The file-descriptor abstraction is Week 7’s; memory-mapped I/O is Week 8’s address space. Network and device inspection feed the syslens capstone (open sockets, devices).