System calls and kernel mode
How a user program asks the operating system for a service: user and kernel mode, the mode bit and privileged instructions, the trap that switches modes, the system call table and parameter passing, library wrappers, and the difference between a mode switch and a context switch.
Why it exists
An operating system must protect itself and the other programs from any one program. A user program therefore may not touch hardware, other programs' memory or the kernel's data directly. But programs need services that only the kernel can perform: open a file, create a process, send data over a network. A system call is the controlled doorway: the program asks, the processor switches into a privileged state at a fixed entry point of the kernel, the kernel checks the request and performs it, and control returns to the program. GATE asks which instructions are privileged, how a system call differs from a function call and from an interrupt, what happens in what order, and which library calls actually use system calls.
Prerequisites
A system call enters the kernel through the same mechanism as an interrupt: the processor saves the return address, changes mode and jumps to an address from a vector.
Precise definitions
Kernel. The part of the operating system that runs with full privileges, always in memory: process and memory management, file systems, device drivers, interrupt handling.
Dual-mode operation. The hardware has (at least) two modes, shown by a mode bit: user mode and kernel mode (also called supervisor, system or monitor mode). User programs run in user mode, the kernel in kernel mode.
Privileged instructions. Instructions that are legal only in kernel mode; executing one in user mode causes a trap (an exception) to the kernel, which usually terminates the program. Typical examples:
- instructions that perform I/O or access device registers (in isolated I/O),
- halt the processor,
- change the mode bit (to kernel),
- enable or disable interrupts,
- set the timer, load the page table base register or other memory-management registers,
- load the base and limit registers,
- clear memory protection information.
Instructions such as add, load from the program's own memory and the trap instruction itself are not privileged.
System call. A request, made by a user program, for a service of the kernel, performed by executing a special instruction (trap, syscall, svc, int) that deliberately causes a software interrupt. The steps:
- The program places the system call number and the arguments in agreed places (registers, or the stack, or a memory block whose address is in a register).
- It executes the trap instruction. The hardware pushes the return address and status on the kernel stack, sets the mode bit to kernel, and loads the PC from a trap vector: the program cannot choose where the kernel starts.
- The kernel's handler validates the request: a valid call number, and any pointer arguments pointing into the caller's own address space. It then uses the number to index the system call table, a table of kernel routine addresses, and runs the routine.
- The result (or an error code) is placed where the program will find it.
- A return-from-trap instruction restores the PC and the status and switches back to user mode.
Library wrapper. In C a program calls an ordinary function such as write(). It is a small routine in the C library that loads the number and arguments and executes the trap. Higher-level functions such as printf build the text in a user-space buffer and call write only when the buffer is flushed. Functions such as strlen or sqrt need no kernel service and make no system call at all.
Kinds of system calls. Process control (fork, exec, exit, wait), file management (open, read, write, close), device management, information maintenance (getpid, time), communication (pipe, sockets, shared memory) and protection.
Mode switch versus context switch. A system call changes the mode (user to kernel and back) within the same process; the kernel code runs on behalf of the calling process. A context switch replaces the running process by another one. A mode switch is much cheaper; a context switch may follow a system call only if the call blocks or the scheduler chooses another process (context switching).
Protection beyond the mode bit. Dual mode is the base of three protections: of the CPU (a timer interrupt returns control to the kernel so that no program can keep the CPU forever), of memory (base and limit registers or page tables confine a program to its own addresses) and of I/O (all I/O instructions are privileged, so all I/O goes through system calls).
How it works
The animation runs one system call, write with the number 4, on a machine with a trap instruction. Watch the MODE register: it is user until the trap, kernel while the handler runs, and user again only when the return-from-trap executes. The return address goes onto the kernel stack, the handler address comes from the trap vector, and the call number selects the routine from the table.
A system call: write(fd, buffer, 12) through a trap: step 1
Machine run, not typed(user program running)| addr | decimal | meaning | |
|---|---|---|---|
| 0C8 | user: R0 <- 4 (write) | PC | |
| 0C9 | user: R1 <- 64 (buffer address) | ||
| 0CA | user: TRAP #0 | ||
| 0CB | user: next instruction | ||
| 00A | 500 | trap vector: handler address | |
| 00B | sys_read | syscall table[1] = sys_read | |
| 00C | sys_write | syscall table[4] = sys_write | |
| 1F4 | kernel: check R0 and the pointer in R1 | ||
| 1F5 | kernel: call sys_write (table[R0]) | ||
| 1F6 | kernel: RET <- bytes written | ||
| 1F7 | kernel: RETURN-FROM-TRAP | ||
| 384 | . | kernel stack (saved state) |
Step 1
A user program wants to print 12 bytes. It runs in USER MODE: the mode bit says it may not execute privileged instructions (I/O, changing the page table, disabling interrupts) or touch kernel memory. To ask the kernel for a service it must make a SYSTEM CALL. The call number goes in R0 (4 = write) and the arguments in registers (here the buffer address in R1).
Worked examples
EX 1A wrapper, a return value and an error
Easywrite() is a library function that makes the write system call. A successful call returns the number of bytes written; a failing call returns and sets errno.
#define _POSIX_C_SOURCE 200809L
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main(void) {
/* write() is a library wrapper around the write system call */
long n = write(1, "hello\n", 6);
printf("write returned %ld\n", n);
errno = 0;
long bad = write(-1, "x", 1);
printf("write on an invalid descriptor returned %ld, errno says: %s\n", bad, strerror(errno));
return 0;
}hello
write returned 6
write on an invalid descriptor returned -1, errno says: Bad file descriptorReading it. The first call went through the trap into the kernel, which copied the six bytes to the terminal's driver and returned 6. In the second call the kernel's validation failed (descriptor is not an open file), so the kernel returned an error code that the wrapper turned into and errno. The check happens in the kernel, because the kernel cannot trust the arguments of a user program.
EX 2Which instructions are privileged?
Easy| Instruction | Privileged? | Why |
|---|---|---|
ADD R1, R2 | no | ordinary computation |
LOAD R1, [addr] in the program's own memory | no | checked by memory protection, not by the mode bit |
TRAP #0 (the system-call instruction) | no | it is the way into the kernel, so it must be allowed |
| Set the mode bit to kernel | yes | else any program could grant itself privilege |
| Disable interrupts | yes | else a program could keep the CPU |
| Set the timer | yes | the timer protects the CPU |
| Load the page table base register | yes | it controls what memory a program can reach |
Execute an I/O (IN/OUT) instruction | yes | I/O is controlled by the OS |
| Read the clock | usually no | harmless to read; setting the clock is privileged |
Trying a privileged instruction in user mode raises an exception and the kernel terminates the program.
EX 3Count the mode switches
MediumA program calls read on a file. Mode switches: user to kernel at the trap, and kernel to user at the return: two. If the data is not in memory, the kernel starts a disk read and blocks the process: the scheduler then performs a context switch to another process; when the disk interrupt arrives (an extra kernel entry, caused by the device, not by the program) and the process is scheduled again, another context switch and the return to user mode follow. So one read can cost two mode switches, one or two context switches and one device interrupt, but a read that hits the page cache costs just the two mode switches.
EX 4Function call versus system call
Medium| function call | system call | |
|---|---|---|
| Instruction | call (jump and push return address) | trap (software interrupt) |
| Mode | stays in user mode | user to kernel and back |
| Return address stored | on the user stack | on the kernel stack |
| Target address | any address the program chooses | fixed, from the trap vector |
| Arguments | checked by no one | validated by the kernel |
| Cost | a few cycles | far more (mode switch, kernel entry and checks) |
Because the cost is high, libraries batch work: printf collects text in a buffer and one write sends it.
EX 5Which of these calls the kernel?
GATE levelTaking each library function in turn: strlen(s) is pure computation on user memory: no system call. sqrt(x) is computed by the library or the FPU: no. printf("...") formats into a buffer and eventually calls write: yes, though not at every call (the buffer is flushed on a newline to a terminal, when it is full, or at exit). malloc(n) usually carves memory from an area it already has: sometimes (when it must ask for more address space, through brk or mmap). fork() and exit() are system calls. A function call from your own program to your own function is not. The distinguishing question is always: does this need the kernel to do something on the program's behalf?
Cheat box
Cheat box
- Two modes: user and kernel (mode bit). Privileged instructions only in kernel mode; using one in user mode causes a trap.
- Privileged: I/O, halt, set mode bit, enable/disable interrupts, set timer, load page table base or limit registers.
- The trap instruction is NOT privileged; it is the only legal way into the kernel.
- System call steps: number and arguments in registers or stack, trap, hardware saves PC on the kernel stack and sets the mode bit, jump through the trap vector, validate, table lookup, run, return value, return-from-trap.
- Parameters: registers, a memory block (address in a register), or the stack.
- Mode switch (same process, cheap) is not a context switch (changes process).
- A library function is a system call only if it needs the kernel (
write,fork,open);strlenandsqrtdo not.
Traps and GATE patterns
Connections
Builds on
Across subjects
Within this subject
Journeys that pass through here
The entry is an interrupt taken on purpose (a software interrupt). Saving the return address is the mechanism of a call, but on the kernel stack and with a mode change. The process services most often requested are those of the process model, and when a call blocks the kernel performs a context switch. Ordinary parameter passing between functions is treated in parameter passing.
PYQs
3 previous year questions from your book. I re-solved each one myself (0 by running or simulating, 3 by reasoning only); the book's key is shown next to my answer. All PYQs
Which one or more of the following options guarantees that a computer system will transition from user mode to kernel mode?
- (a)function call
- (b)malloc call
- (c)page fault
- (d)system call OPERATING SYSTEMS
Which of the following standard C library functions will always invoke a system call when executed from a single-threaded process in a UNIX/Linux operating system?
- (a)exit
- (b)malloc
- (c)sleep
- (d)strlen
Let the time taken to switch between user and kernel modes of execution be t1 while the time taken to switch between two processes be t2. Which of the following is TRUE?
- (a)(t1) > (t2)
- (b)(t1) = (t2)
- (c)(t1) < (t2)
- (d)Nothing can be said about the relation between t1 and t2
Self-check
Question 1
Name two instructions that must be privileged and one that must not be, though it enters the kernel.
Show answerHide
Disabling interrupts and setting the mode bit (also setting the timer, I/O instructions) must be privileged. The trap instruction is not privileged.
Question 2
Why is the return address of a system call pushed on the kernel stack and not on the user stack?
Show answerHide
The user's stack pointer cannot be trusted: it could point into kernel memory or be invalid. The kernel uses its own stack for the process.
Question 3
How many mode switches does a successful getpid() call involve?
Show answerHide
Two: user to kernel at the trap and kernel to user at the return.
Question 4
How can the kernel make sure that the system call table lookup uses a valid index?
Show answerHide
The handler compares the call number with the number of entries before indexing the table, and rejects anything else with an error.
Revision card
One-screen revision
- Mode bit: user or kernel. Privileged instructions fault in user mode. TRAP is allowed and is the only way into the kernel.
- Trap: hardware saves PC on the kernel stack, sets kernel mode, loads PC from the trap vector.
- Handler validates the number and pointers, looks up the system call table, runs, returns a value; return-from-trap restores user mode.
- Library wrappers hide the trap;
printfcallswritesometimes;strlennever does. - Mode switch is not a context switch.
References
- ·Silberschatz, Galvin, Gagne, Operating System Concepts, Chapter 1 Introduction (dual-mode operation) and Chapter 2 Operating-System Structures (system calls)
- ·Tanenbaum and Bos, Modern Operating Systems, Chapter 1 Introduction (system calls)
- ·Stallings, Operating Systems: Internals and Design Principles, Chapter 2 Operating System Overview (modes of execution)
Verification
The animation is a run of a teaching machine (scripts/gen-os-proc-traces.py) re-checked by tests/os-proc-traces.test.ts: the mode is kernel only between the trap and the return, the PC resumes after the TRAP, and the result is delivered in RET. The C program on this page (npm run verify:c) calls the real write system call through its library wrapper and shows a failing call. The machine's trap vector, call numbers and registers are an idealised model; real processors and kernels differ in the instruction used (trap, syscall, svc, int), in which registers carry the arguments and in the numbering. Textbook chapter titles are from memory. SECOND PASS (2026-11-02, done by the assistant, not a human check): every Self-check question was solved before the printed answer was read and all agreed; the definitions, worked examples, cheat box and traps were read claim by claim and the numbers re-derived by hand. One wording defect fixed (which steps of a system call the hardware does). Status raised to self-checked; verified needs a textbook or human check.
last verified: never
My notes (saved in this browser)