为何存在系统调用？用户空间程序为何无法直接执行内核级操作？

Great question—this cuts to the core of how operating systems balance functionality, security, and stability. Let’s break down your questions one by one:

1. Why Can’t User-Space Programs Perform Operations Directly? #

The short answer: hardware-enforced privilege isolation is critical for system safety and stability.

• CPU Ring Levels as a Security Boundary: CPUs like x86 use ring levels (0 to 3) to restrict access to sensitive resources. Kernel code runs in Ring 0 (kernel mode), which has full access to hardware, memory, and kernel data structures. User-space programs run in Ring 3 (user mode), with strict permissions—they can’t directly write to disk, access other processes’ memory, or interact with hardware.
• Preventing Chaos: If every program could directly manipulate system resources, a buggy or malicious program could easily corrupt system files, crash the entire OS, or steal data from other processes. System calls act as a "gatekeeper": the kernel first validates the request (e.g., "does this user have permission to open that file?") before executing the operation, preventing unauthorized or dangerous actions.
• Example: Imagine if your program could directly write to disk sectors. A simple off-by-one error could overwrite the kernel’s boot sector, rendering your system unbootable. System calls eliminate this risk by routing all resource operations through the kernel’s validated code.

2. Why Does Glibc Act as a Wrapper for System Calls Instead of Executing Operations Directly? #

Glibc’s role is to provide a portable, user-friendly layer between your code and the kernel, not to replace it. Here’s why this matters:

• Cross-Platform Abstraction: The C standard library (like fopen()) is designed to work across all UNIX-like systems (Linux, BSD, macOS, etc.). System calls are OS-specific: Linux uses open(), while BSD might use openat(), and macOS has its own variations. Glibc hides these differences—your fopen() call works the same everywhere, because Glibc maps the standard function to the correct system call for the underlying OS.
• Added Functionality: fopen() does far more than just call open(). It creates a user-space buffer (part of the FILE struct) to reduce the number of expensive system calls (since each syscall involves a mode switch between user and kernel space). It also handles error code translation, thread safety, and stream management—tasks that would be tedious to implement in every program.
• Maintainability: If the kernel changes its system call interface (e.g., adding a new parameter), only Glibc needs to be updated. Your code remains untouched. If every developer had to call system calls directly, kernel updates would break countless programs overnight.

3. A Deep Dive into fopen() vs. open() #

Let’s walk through what happens when you call fopen("file.txt", "r"):

1. Glibc first validates your input (e.g., checking that the filename isn’t null).
2. It triggers the open() system call, which causes the CPU to switch from user mode to kernel mode (via a syscall instruction or legacy interrupt like int 0x80).
3. The kernel checks your user permissions, locates the file’s inode, and allocates a file descriptor.
4. The kernel returns the file descriptor to Glibc.
5. Glibc creates a FILE struct, which stores the file descriptor, buffer, current read/write position, and other metadata. It returns a pointer to this struct to your program.

Glibc can’t "directly execute" the file-opening operation because it runs in user mode—without kernel-level privileges, it can’t access the kernel’s file system data structures or interact with the disk hardware. All resource operations must go through the kernel via system calls.

内容的提问来源于stack exchange，提问作者user8396910