Linux System Calls

File system

The file is the most basic and fundamental abstraction in Linux. Linux follows the everything-is-a-file philosophy. Consequently, much interaction transpires via filesystem system calls such as reading of and writing to files, even when the object in question is not what you would consider your everyday file.

In order to be accessed, a file must first be opened. Files can be opened for reading, writing, or both. An open file is referenced via a unique descriptor, a mapping from the metadata associated with the open file back to the specific file itself. Inside the Linux kernel, this descriptor is handled by an integer (of the C type int) called the file descriptor, abbreviated fd. File descriptors are shared with user space, and are used directly by user programs to access files. A large part of Linux system programming consists of opening, manipulating, closing, and otherwise using file descriptors.

Network

Like most other Unix-based operating systems, Linux supports TCP/IP as its native network transport. Network system calls is the way to make communications between computes via different kind of network interfaces: wired and wireless devices, fiber channel and etc. Most of network operations are based on BSD sockets interface.

Sockets allow processes on different computers to exchange data through a network. Sockets can also be used as a communication tool for processes located on the same host computer; the X Window System graphic interface, for instance, uses a socket to allow client programs to exchange data with the X server.

Time

The kernel measures the passage of time in three different ways: wall time (or real time), process time and monotonic time. These three measurements of time may be represented in one of two formats: relative time and absolute time. Managing the passage of time on a Linux system involves several tasks, only some of which any given process is concerned with: they include setting and retrieving the current wall time, calculating elapsed time, sleeping for a given amount of time, performing high-precision measurements of time, and controlling timers. This is accessible via Linux time system calls.

Process management

Processes are the most fundamental abstraction in a Linux system, after files. As object code in execution - active, alive, running programs - processes are more than just assembly language; they consist of data, resources, state, and a virtualized computer.

Linux took an interesting path, one seldom traveled, and separated the act of reating a new process from the act of loading a new binary image. Although the two tasks are performed in tandem most of the time, the division has allowed a great deal of freedom for experimenta tion and evolution for each of the tasks. This road less traveled has survived to this day, and while most operating systems offer a single system call to start up a new program, Linux requires two: a fork and an exec.

Signals

Signals are software interrupts that provide a mechanism for handling asynchronous events. These events can originate from outside the system - such as when the user generates the interrupt character (usually via Ctrl-C) - or from activities within the program or kernel, such as when the process executes code that divides by zero. As a primitive form of interprocess communication (IPC), one process can also send a signal to another process.

Inter Process Communication

Allowing processes to exchange information and notify each other of events is one of an operating system’s most important jobs. The Linux kernel implements most of the historic Unix IPC mechanisms - including those defined and standardized by both System V and POSIX - as well as implementing a mechanism or two of its own. IPC mechanisms supported by Linux include pipes, named pipes, semaphores, message queues, shared memory, and futexes.

Non-uniform memory access

We are used to thinking of the computer’s memory as a homogeneous, shared resource. Disregarding the role of the hardware caches, we expect the time required for a CPU to access a memory location to be essentially the same, regardless of the location’s physical address and the CPU. Unfortunately, this assumption is not true.

Linux supports the Non-Uniform Memory Access (NUMA) model, in which the access times for different memory locations from a given CPU may vary. The physical memory of the system is partitioned in several nodes. The time needed by a given CPU to access pages within a single node is the same. However, this time might not be the same for two different CPUs. For every CPU, the kernel tries to minimize the number of accesses to costly nodes by carefully selecting where the kernel data structures that are most often referenced by the CPU are stored.

Linux key management

The keyrings facility is primarily a way for drivers to retain or cache security data, authentication keys, encryption keys and other data in the kernel. System call interfaces are provided so that userspace programs can manage those objects and also use the facility for their own purposes. The facility has a number of users and usages, but is not limited to those that already exist.

In-kernel uses of this facility include: Network filesystems (DNS), NFS (user ID mapping), CIFS (Password), module verification.

Userspace uses of this facility include Kerberos key storage.

System-wide

This section covers system calls, which can not be assigned to any other sections. Such system calls usually provide system wide information about kernel and whole operation system. Also they can change typical behavior of Linux and extend its functionality by loadable modules.