System programmers must know about system calls and for for those who are not system programmers, it is still good getting to know about how things work under the hood. My idea here is to do a series of blog posts on UNIX/Linux system internals for the upcoming weeks. I'm doing this as a part of my learnings from CodeSchool and reading Linux System Programming. Let's get started with UNIX System Calls in the first place.
From Linux System Programming book,
System programming starts and ends with system calls. System calls (often shortened to syscalls) are function invocations made from user space—your text editor, favorite game, and so on—into the kernel (the core internals of the system) in order to request some service or resource from the operating system. System calls range from the familiar, such as read() and write(), to the exotic, such as get_thread_area() and set_tid_address().
So system calls acts as an intermediary between userspace applications and the kernel space. It allows programs to request the operating system to do something on its behalf. The system calls are functions used in the kernel itself. If there was no clear distinction between the kernel space and user space, then all the user applications will be able to do absolutely anything they want to do in the operating system. Now that would be insecure and chaotic. System calls exposes only those functionalities of the kernel through an API which will get only that task done for the user application. In short, its a secure way of getting things done in the operating system.
All of us are atleast familiar with the
write() system calls. But applications need
even more of these. the following table shows the most commonly used system calls.
|General Class||Specific Class||System Call|
|File related||Creating a Channel||creat()|
|Process related||Process creation||exec()|
|Process Owner & Group||getuid()|
|Change working directory||chdir()|