Drivers, System Calls and I/O | IT Foundations for Beginners

In this chapter

We'll learn how programs and hardware actually meet: drivers, system calls, interrupts, I/O and device management — the doorway every program walks through to use the computer.

12–14 min

The Problem in Real Life

After the permission fix, Anna saves the config file again. This time it works instantly. She's curious. "My code just said save the file. How did that end up as bytes on the SSD? My code doesn't know anything about SSDs."

"Right," says John. "And it's not allowed to. User space, remember? So it has to ask. Let's follow one save, all the way down."

My code never talks to the SSD. So who does?

Anna

"My Code Saves a File" vs. What Really Happens

One action, many layers

Saving a file passes through the program, the kernel, a driver and the hardware.

Hardware speaks its own language

Every SSD, keyboard and Wi-Fi chip is different. Drivers translate.

Hardware interrupts the CPU

When a key is pressed or data arrives, the hardware signals the CPU immediately.

Drivers, System Calls, Interrupts and I/O

Everything a program does that goes beyond its own memory — files, network, screen, keyboard, time — goes through the operating system. Here are the pieces that make that work:

System call — the official way a program asks the kernel to do something for it. Common ones: open a file, read, write, close, start a new process, send data over the network. When a program makes a system call, the CPU switches from user mode to kernel mode, the kernel checks the request (including permissions — the last chapter), does the work, and switches back. Programmers rarely call these directly; libraries and runtimes like Node.js do it for them.
Driver — a piece of software that knows how to control one specific kind of hardware. The kernel says "write these bytes to storage," and the SSD's driver turns that into the exact commands that particular SSD understands. Drivers usually run in kernel space. A new printer or graphics card needs a driver before the OS can use it — and a bad driver is a common cause of crashes.
I/O (Input/Output) — any data going in or out of the computer or between its parts: reading a file, receiving a network message, a key press, drawing on the screen. I/O is very slow compared to the CPU. A program waiting for I/O is moved to the waiting state (chapter 2) so the CPU can run something else in the meantime.
Interrupt — a signal from hardware that tells the CPU "something happened, deal with me now." A key press, a network packet arriving, or an SSD finishing a read all trigger interrupts. The CPU pauses what it's doing, runs a small piece of kernel code to handle it, then carries on. A timer interrupt that fires many times per second is how the scheduler takes the CPU back to give another thread its turn.
Device management — the OS keeps a list of every connected device, loads the right driver, gives programs a simple way to use each device, and makes sure two programs don't fight over the same one (two apps can't print on top of each other — the OS puts print jobs in a queue).

Table — Common system calls (Linux names)

System call	What it asks the kernel to do
open	Open a file and give back a handle to it
read / write	Read bytes from, or write bytes to, a file or connection
close	Finish using a file
fork / exec	Start a new process / run a program in it
socket / connect	Open a network connection
exit	End this process with an exit code

Table — Interrupts you cause every day

Event	Interrupt from	What the OS does
You press a key	Keyboard	Reads the key and passes it to the active app
A web page's data arrives	Network card	Hands the data to the waiting browser
A file finishes loading	SSD	Wakes the program that was waiting
A few milliseconds pass	Timer	Lets the scheduler switch threads

Following one file save, top to bottom

Anna's code

"save config.json"

calls

Library / runtime (Node.js)

turns it into a system call

asks the kernel

System call: write

CPU switches to kernel mode

Kernel + file system

check permissions, choose where the bytes go

passes to

SSD driver

translates into SSD commands

controls

SSD hardware

stores the bytes, then sends an interrupt

Now let's follow Anna's one save, all the way down:

1. Her code calls a library function to save the file. 2. The library (inside Node.js) makes a system call — write. 3. The CPU switches to kernel mode; the kernel checks permissions and asks the file system where the data should go. 4. The kernel passes the request to the SSD's driver. 5. The driver tells the SSD controller to store the bytes. The program, meanwhile, may wait. 6. When the SSD is done, it sends an interrupt. 7. The kernel marks the request complete, wakes the program, and returns to user mode. All of this takes far less than a second.

This is the meeting point of hardware and software we first saw in Act 02's boot chain. Every program, on every computer, uses the same pattern.

Key Takeaway

Programs never touch hardware directly. They make system calls; the kernel checks and handles them, using drivers to control each device. Hardware reports back with interrupts, and slow I/O makes programs wait while the CPU does other work.

Why This Matters

This is why a slow disk or network makes software slow even when the CPU is idle — the program is waiting on I/O. It's why updating a driver can fix a crash, and why BlueTicket's app, which spends most of its time waiting for the database and the network, is designed to do other work while it waits (you'll see this in Act 23). Thinking "where is this program waiting?" is one of the most useful debugging habits there is.

Anna has seen the whole OS from the inside: processes, memory, files, permissions and system calls. One last question from her first week: her laptop runs Windows, but BlueTicket's servers run Linux. Why not the same everywhere?