Chapter 0 — Introduction: The Linux Hardware Philosophy

Everything Is a File

In Linux, one design principle dominates all others: everything is a file.

Your hard drive? A file (/dev/sda). Your terminal? A file (/dev/pts/0). The CPU temperature sensor? A file (/sys/class/thermal/thermal_zone0/temp). The list of running processes? A file (/proc). Even network sockets, pipes, and inter-process communication channels are represented as file descriptors in the kernel.

This is not just a metaphor. It is the actual mechanism. When a Python program reads from a serial port, it opens a file, calls read(), and gets bytes back — the same operations used to read a text file. The kernel handles the rest.

# Reading from a serial port is just reading a file
with open("/dev/ttyUSB0", "rb") as port:
    data = port.read(64)

This uniformity is powerful. It means that the same tools — cat, echo, read(), write() — work at every layer of the system.

Why Should a Python Developer Care?

Python hides a lot. Its standard library wraps system calls, its runtime manages memory, and its ecosystem provides libraries for almost everything. You can write production software for years without thinking about hardware.

But hardware leaks through. You encounter it when:

• A USB device isn’t detected and you need to debug why
• A sensor driver returns unexpected values
• You need to control a GPIO pin on a Raspberry Pi
• Serial communication fails and you can’t tell if it’s a config issue or a hardware issue
• A process uses 100% CPU and you need to understand if it’s I/O wait or computation
• You’re building an IoT system and need to understand the difference between SPI and I2C

Understanding the layer beneath Python makes you a more effective debugger, a better system designer, and capable of reaching hardware directly when no library exists.

The Stack You’re Building a Mental Model Of

Here is the full stack from a Python function call to a physical hardware operation:

Python code
    │  open(), read(), write(), ioctl()
    ▼
Python runtime (CPython)
    │  wraps POSIX calls
    ▼
C standard library (libc)
    │  wraps Linux system calls
    ▼
Linux system call interface
    │  e.g. sys_read(), sys_write(), sys_open()
    ▼
Linux kernel (VFS layer)
    │  dispatches to the right filesystem
    ▼
Device driver (kernel module)
    │  talks to specific hardware
    ▼
Hardware bus (PCI, USB, I2C, SPI...)
    │  electrical protocol
    ▼
Physical hardware (chip, sensor, disk...)

This book explores each layer. By the end, each arrow in this diagram will have a concrete meaning for you.

The Kernel/Userspace Boundary

The most important boundary in this stack is between userspace and kernel space.

Your Python program runs in userspace. It has no direct access to hardware, no ability to execute privileged CPU instructions, and no direct access to physical memory. This is by design — if any program could freely access hardware, one buggy script could crash the entire machine.

The kernel runs in kernel space, with full hardware access. When your program needs something from hardware, it crosses the boundary through a system call (syscall). A syscall is a controlled gate into the kernel.

Userspace:  your Python program, libraries, shell
─────────────── syscall boundary ───────────────
Kernel space: kernel, drivers, hardware access

You cross this boundary constantly without noticing. open(), read(), write(), socket(), mmap() — all syscalls. The kernel validates the request, performs the hardware operation, and returns control to your program.

The Virtual Filesystems

A key concept you’ll encounter repeatedly is the virtual filesystem (VFS). These are filesystems that don’t correspond to real storage on disk. Instead, they are kernel data structures exposed as a file hierarchy.

You will spend a lot of time in these three directories. They are your primary window into the kernel’s view of the hardware.

What This Book Is Not

This book does not teach you to write kernel drivers in C. It does not cover kernel internals at the source code level. It does not require any knowledge of C or assembly.

It focuses on the interface the kernel exposes to userspace — the files, the sysfs attributes, the proc entries — and how to use them from Python.

Next: Chapter 1 — The Linux Kernel: Referee Between Software and Hardware

Back to Table of Contents