Introduction to system calls
System calls, often called “syscalls,” are fundamental to an operating system’s interface. They are low-level functions provided by the operating system kernel that allow user-level processes to request services from the kernel.
If you are new to the concept, some analogies could make understanding more effortless. Let’s correlate the idea with traveling.
User mode versus kernel mode
A processor (or CPU) has two modes of operation: user mode and kernel mode (also known as supervisor mode or privileged mode). These modes dictate the level of access and control that a program has over system resources. User mode is restricted and doesn’t allow direct access to certain critical system resources, while kernel mode has more privileges and can access these resources. Permission granted, proceed with caution
When it comes to system calls, the kernel plays the role of a strict border control officer. System calls are like the passports we need to navigate the diverse landscapes of software execution. Think of the kernel as a heavily fortified international border checkpoint. Just as travelers need permission to enter a foreign land, our processes require approval to access the kernel’s resources. System calls serve as passports, allowing us to cross the border between user and kernel spaces.
The catalog of services and identification
Much like a traveler’s guidebook, the kernel offers a comprehensive catalog of services through the system call application programming interface (API). These services range from creating new processes to handling input and output (I/O) operations such as amenities and attractions in a foreign country.
A numerical code uniquely identifies each system call, like your passport number. However, this numbering system remains hidden from everyday use. Instead, we interact with system calls by their names, much like travelers identifying services and landmarks by their local names rather than their codes. For instance, an open system call might be identified by the number 5 in the kernel’s internal system call table. However, as programmers, we refer to this system call by its name, “open,” much like travelers identify places by their local names rather than their GPS coordinates.
The location of the system call table depends on the OS and the architecture, but if you are curious about these identifiers, you can visit a handcrafted table at the following link:
https://filippo.io/linux-syscall-table/
Information exchange
System calls are not one-way transactions; they involve a careful exchange of information. Each system call comes with arguments that dictate what data needs to travel between user space (your process’s domain) and kernel space (the kernel’s realm). Picture it as a well-coordinated cross-border conversation, where information passes seamlessly between the two sides.
When you use the write() system call to save data to a file, you pass not only the data but also information about where to write it (for example, a file descriptor and a data buffer). This data exchange is like a conversation across borders, with data moving seamlessly between the user and kernel spaces.
