System Calls: the Official Counter Where a Program Asks the OS

A Program Is Locked Inside a Fence (User Mode)

Earlier we said the operating system builds a wall so programs cannot invade one another's memory. That wall applies to hardware just the same. An ordinary program cannot reach straight into the disk, cannot put a dot on the screen directly, cannot touch the network line itself. It is as if it sits inside a fence. This penned-in state is called user mode. It looks stifling, but there is a reason. If just any program could handle hardware directly, a single buggy or malicious program could wreck the entire computer.

Make the program reach straight for the disk. The wall blocks it (red). A program in user mode cannot touch hardware directly.

Every time it reached out directly, it was blocked. For safety that is only natural. But then it seems strange. The programs we use every day open files just fine, show photos, and connect to the internet. If they are penned in, how on earth do they pull those things off? The secret is that they do not do it themselves; they ask. Next, let us see how that asking works.

The Fix: Ask at an Official Counter (a System Call)

At a bank we do not walk into the vault ourselves. We go to the counter, hand over a request slip, and a clerk who holds the keys takes care of it for us. A program is just the same. Unable to open the disk itself, it goes to the operating system's counter and asks. "Please open this file." "Please put these letters on the screen." "Please send this over the internet." Each such request handed to the operating system is called a system call. The key point is that the program does not do the work itself; it has the operating system do it, because the operating system has the privilege.

Tap the request slip to ask at the counter. The program (gold) hands open file to the OS counter (blue), and the OS does it and returns the result (green).

By asking at the counter, what was impossible became possible. The program is still inside the fence, yet through its agent, the operating system, it got an outside job done. But one thing is curious. It is the very same disk, so why is it blocked when the program touches it and fine when the operating system touches it? In that brief instant of crossing the counter, something clearly changes. Next, let us look closely at that change.

Crossing the Counter Flips the Privilege (User Mode and Kernel Mode)

The secret is that the CPU has two modes. One is user mode, the power-limited world where our programs live. The other is kernel mode, the operating system's powerful world where it can touch hardware and anything else. Normally a program runs in user mode. Then, the instant a system call crosses the counter, the CPU briefly flips to kernel mode. With that strong privilege the operating system handles the requested job, and when it is done it flips right back to user mode and hands the result to the program. The strong power is granted only for the moment of handling the request, and only at this counter, and then it is taken back.

Tap make a system call. The program runs in user mode (gold), flips to kernel mode (blue) the moment it crosses the counter, does the work, and returns to user mode.

This little dance, the mode flipping briefly and coming back, is actually the heart of the operating system's safety. The power is not always on; it switches on for just the instant a request arrives, then off. But here a question arises. If the operating system simply did whatever was asked the moment you crossed the counter, how would that differ in the end from the program touching hardware directly? So the counter has one more job: checking. Let us see it next.

One Counter Means It Can Be Checked (the Permission Check)

If the operating system did everything the moment it was asked, with no questions, the counter would be just a pass-through point. But the operating system does not do that. Because every request must pass through this one counter, the operating system can check first, before doing the work. "Do you have permission to read this file?" The very permission check we saw last lesson happens right here. If the permission is there, it does the job; if not, it refuses and returns an error. One narrow counter becomes the checkpoint that every dangerous action must pass.

Pick a request and send it to the counter. The OS checks permission. An allowed request is done (green); a forbidden one (say, writing someone else's file) is refused (red) with an error returned.

An allowed request passed, and a forbidden one was stopped at the door. The counter being narrow was not an inconvenience but a safeguard. Since every dangerous action must pass one place, the rules only need to be enforced at that one place. Now let us thread it all on a single line: the fence of user mode, the asking that is a system call, the briefly flipped kernel mode, and the check at the counter.

In Summary: the Round Trip on One Line, and the Kernel Behind the Counter

Seen on one line, it goes like this. A program runs inside the fence of user mode, unable to touch hardware directly. When it needs something, it asks at the official counter with a system call. The instant it crosses, the CPU briefly flips to kernel mode, and the operating system first checks permission, then does the work. When it is done, it returns to user mode and hands back the result. So a system call is the single, well-guarded door joining a program to the operating system's power. Every time we open a file, put one dot on the screen, or send something over the internet, all of it quietly passes through this door.

Tap the steps in order to follow one full loop. From user program to system call, to the kernel-mode switch and permission check, to doing the work and returning the result. The round trip on one panel.

But behind that counter, who is it that actually does the work with the powerful force of kernel mode? The deepest center of the operating system, the core that holds every privilege and speaks directly with the hardware, has a name. It is the kernel. A system call was, in the end, a request sent to this kernel. In the next lesson we finally meet the kernel face to face. We will see, all in one place, in whose hands the scheduling, memory, files, permissions, and counter we have watched were turning all along.