System Calls in Operating Systems

• Definition — A System Call is a programmatic way for a computer program to request a service from the kernel of the operating system.
• Core Concept — It acts as the bridge between User Mode (where applications run) and Kernel Mode (where the OS controls hardware).
• Key Objective — To allow user-level programs to access restricted resources (like the Hard Disk or Printer) safely and securely.

Introduction to System Calls

When you write a program in C or Python to "print" text to the screen or "save" a file, your program cannot do it directly. Accessing hardware is dangerous; if every program could touch the hard disk directly, one bug could wipe your entire system. Instead, your program asks the Operating System to do it. This "ask" is the System Call.

Think of system calls as the receptionist at a secure building. You can't just walk into the restricted areas (hardware); you must ask the receptionist (OS kernel) to access them for you. This ensures security, prevents conflicts, and maintains system stability.

Need for System Calls

Hardware Abstraction

Programmers don't need to know the physics of a hard drive; they just call write().

Without System Calls — to save a file, a programmer would need to:

• Calculate exact disk sector locations
• Control spindle motor speed (5400/7200 RPM)
• Position read/write head using stepper motors
• Manage disk cache and buffer
• Handle concurrent access from other programs
• Implement error correction codes and deal with bad sectors

With System Calls — one line replaces all of the above:

write(file_descriptor, data, size);

The OS kernel handles all the hardware complexity behind that single call.

Security

Prevents applications from accessing memory or devices they shouldn't touch.

• Memory Protection: Program A cannot read Program B's memory
• Resource Isolation: No app can monopolize CPU or RAM
• Access Control: Only authorized programs can access files
• Privilege Separation: User apps cannot execute privileged instructions

Without this protection, a malicious program could freely:

• Read passwords from another program's memory
• Wipe the entire hard disk
• Disable antivirus software
• Access the webcam without permission

System calls prevent this by requiring OS kernel permission for every hardware access.

Portability

A program using standard system calls can run on different hardware without changing the code.

Example: A program using POSIX system calls works on:

• Linux on Intel x86
• Linux on ARM (Raspberry Pi)
• macOS on Apple Silicon
• Unix on SPARC processors

The system calls remain the same; the OS handles hardware differences.

Multitasking

Allows the OS to manage competing requests from multiple programs safely.

Scenario: Word, Chrome, and Excel all request the printer simultaneously. With system calls, the OS queues the jobs and serialises them — no conflicts, no garbled output. Without system calls, all three would fight for direct printer control, corrupting each other's output or crashing the system.

1. Each program calls print()
2. OS queues the jobs in order
3. OS dispatches to printer one at a time
4. Result: no conflicts, no data corruption

User Mode and Kernel Mode

To protect the system, modern processors operate in two modes. A system call is the trigger that switches between them.

User Mode (Mode Bit = 1)

Restricted access. Applications run here. They cannot touch hardware directly.

• Limited instruction set — cannot execute privileged CPU instructions
• Cannot access kernel memory or control I/O devices directly
• If a program crashes, only that program fails — the OS stays running

Runs here:

• All user applications (Word, Chrome, games)
• User-level processes and application code

Kernel Mode (Mode Bit = 0)

Privileged access. The OS runs here with full control over the machine.

• Full instruction set — can execute privileged I/O and memory management instructions
• Unrestricted access to all memory and direct hardware control
• If the kernel crashes, the entire system crashes (Blue Screen of Death on Windows)

Runs here:

• OS kernel code
• Device drivers
• System call handlers

Types of System Calls

System calls are generally grouped into six major categories based on what they do.

Process Control

Handles program execution and process management.

#include <unistd.h>
#include <sys/wait.h>

int main() {
    pid_t pid = fork();  // Create child process
    
    if (pid == 0) {
        // Child process
        execl("/bin/ls", "ls", "-l", NULL);  // Run 'ls -l'
    } else {
        // Parent process
        wait(NULL);  // Wait for child to finish
        printf("Child completed\n");
    }
    return 0;
}

File Management

Handles file and directory operations.

#include <fcntl.h>
#include <unistd.h>

int main() {
    int fd = open("data.txt", O_RDONLY);  // Open file for reading
    if (fd < 0) {
        perror("File open failed");
        return 1;
    }
    
    char buffer[100];
    int bytes = read(fd, buffer, sizeof(buffer));  // Read data
    
    close(fd);  // Close file
    return 0;
}

Device Management

Handles peripherals and I/O devices.

int printer = open("/dev/lp0", O_WRONLY);  // Open printer
write(printer, document, size);  // Print document
close(printer);  // Release printer

Information Maintenance

Handles system data and metadata.

#include <time.h>
#include <unistd.h>

int main() {
    pid_t my_pid = getpid();  // Get my process ID
    time_t current_time = time(NULL);  // Get current time
    
    printf("PID: %d\n", my_pid);
    printf("Time: %s", ctime(&current_time));
    return 0;
}

Communication

Handles inter-process communication and networking.

int fd[2];
pipe(fd);  // Create pipe

if (fork() == 0) {
    // Child writes to pipe
    close(fd[0]);
    write(fd[1], "Hello Parent!", 13);
    close(fd[1]);
} else {
    // Parent reads from pipe
    char buffer[20];
    close(fd[1]);
    read(fd[0], buffer, 13);
    printf("Received: %s\n", buffer);
    close(fd[0]);
}

Protection

Handles access control and permissions.

#include <sys/stat.h>

// Set file permissions to rw-r--r-- (644 in octal)
chmod("document.txt", S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

// Or using octal notation
chmod("document.txt", 0644);

Implementation of System Calls

How does code actually trigger the OS?

The API

Programmers rarely write system calls directly (in Assembly). Instead, they use an Application Programming Interface (API) like the Win32 API (Windows) or POSIX API (Linux/Unix).

The Library

The standard C library (libc) provides wrapper functions. When you call printf(), the library internally calls the write() system call.

User Program: printf("Hello World");
      ↓
C Library: Formats string, calls write()
      ↓
write() System Call: Traps to kernel
      ↓
Kernel: Sends data to display driver
      ↓
Hardware: Text appears on screen

Examples of System Calls Across Operating Systems

Here is how different OSs handle common tasks:

Critical Concept: System Call Overhead

System calls are "expensive" in terms of CPU time.

Context Switch

Switching from User Mode to Kernel Mode takes time (~1-5 microseconds per call).

Performance Impact

Scenario: A program makes 1 million system calls. At 2 microseconds per call, the total overhead is 2 seconds of pure overhead.

Optimization Strategies

for (int i = 0; i < 1000000; i++) {
    write(fd, &data[i], 1);  // Write 1 byte at a time
}
// Result: 1 million system calls! Very slow!

write(fd, data, 1000000);  // Write all data at once
// Result: 1 system call! Much faster!

Real-World Impact

• Games: Minimize system calls in render loop (60+ FPS requires <16ms per frame)
• High-Frequency Trading: Every microsecond counts; avoid system calls in critical path
• Database Systems: Use memory-mapped files (mmap()) to reduce I/O system calls
• Web Servers: Use sendfile() instead of read() + write() to avoid copying data

System Calls vs. Operating System Services

(Use this table to answer "Difference between..." questions)

Error Handling in System Calls

System calls can fail (e.g., trying to open a file that doesn't exist).

Return Values

Most system calls return -1 or NULL on failure, and a non-negative value on success.

int fd = open("file.txt", O_RDONLY);
if (fd < 0) {
    // Error occurred!
}

pid_t pid = fork();
if (pid < 0) {
    // Fork failed!
}

Error Codes

The OS sets a global variable (like errno in C) to a specific code so the program knows why it failed.

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>

int main() {
    int fd = open("nonexistent.txt", O_RDONLY);
    
    if (fd < 0) {
        printf("Error: %s\n", strerror(errno));
        
        if (errno == ENOENT) {
            printf("File does not exist!\n");
        } else if (errno == EACCES) {
            printf("Permission denied!\n");
        }
        return 1;
    }
    
    close(fd);
    return 0;
}

Error: No such file or directory
File does not exist!

Best Practices

• Always check return values from system calls
• Use perror() or strerror(errno) for descriptive error messages
• Clean up resources even on error (close files, free memory)
• Log errors for debugging
• Provide user-friendly messages (don't just show errno numbers)

Library Functions vs System Calls

Understanding the relationship between library functions and system calls is crucial for effective systems programming.

1. Library Function Layer (High-Level):
   printf("Number: %d\n", 42);
   ↓
2. Library Implementation:
   Formats string, manages buffer
   ↓
3. System Call Layer (Low-Level):
   write(1, "Number: 42\n", 11);
   ↓
4. Kernel Execution:
   Validates, writes to device
   ↓
5. Hardware:
   Display driver renders text

for (int i = 0; i < 1000000; i++) {
    write(fd, &data[i], 1);  // 1 million system calls
}
// Time: ~2 seconds (due to context switch overhead)

FILE *fp = fopen("file.txt", "w");
for (int i = 0; i < 1000000; i++) {
    fputc(data[i], fp);  // Library buffers internally
}
fclose(fp);  // Flush buffer to disk
// Time: ~0.01 seconds (only ~10 system calls)

When to Use Each