Operating systems have two major jobs: providing abstractions to user programs and managing the computer's resources. Mostly, the interaction between user programs and the operating system deals with the former; for instance, creating, writing, reading, and deleting files. The resource management part is largely transparent to the users and done automatically. In this way, the interface between user programs and the operating system is mostly about dealing with the abstractions. To really understand what operating systems do, we must examine this interface closely. The system calls available in the interface vary from operating system to operating system (although the fundamental concepts tend to be similar).
We are therefore forced to make a choice between (1) vague generalities ("operating systems have system calls for reading files") and (2) some specific system ("UNIX has a read system call with three parameters: one to specify the file, one to tell where the data are to be put, and one to tell how many bytes to read").
We have chosen the latter approach. It's more work that way, but it gives more insight into what operating systems really do. Though this debate particularly refers to POSIX (International Standard 9945-1 ), thus also to UNIX, System V, BSD, Linux, MINIX 3, and so on, most other modern operating systems have system calls that carry out the same functions, even if the details differ. Since the actual mechanics of issuing a system call are highly machine dependent and often must be expressed in assembly code, a procedure library is provided to make it possible to make system calls from C programs and sometimes from other languages as well.
It is beneficial to keep the following in mind. Any single-CPU computer can carry out only one instruction at a time. If a process is running a user program in user mode and needs a system service, such as reading data from a file, it has to carry out a trap instruction to transfer control to the operating system. The operating system then figures out what the calling process wants by inspecting the parameters. Then it executes the system call and returns control to the instruction following the system call. In a sense, making a system call is like making a special kind of procedure call, only system calls enter the kernel and procedure calls do not.
In order to make the system call mechanism clearer, let us take a quick look at the read system call. As mentioned above, it has three parameters: the first one specifying the file, the second one pointing to the buffer, and the third one giving the number of bytes to read. Like nearly all system calls, it is invoked from C programs by calling a library procedure with the same name as the system call: read. A call from a C program might look like this:
count = read(fd, buffer, nbytes);
The system call (and the library procedure) return the number of bytes actually read in count. This value is usually the same as nbytes, but may be smaller, if, for instance, end-of-file is encountered while reading.
In case the system call cannot be executed, either due to an invalid parameter or a disk error, count is set to - 1, and the error number is put in a global variable, errno. Programs should always check the results of a system call to see if an error took place.
System calls are performed in a series of steps. To make this thought clearer, let us observe the read call discussed above. In preparation for calling the read library procedure, which in reality makes the read system call, the calling program first pushes the parameters onto the stack, as shown in steps 1-3 in the following figure.
C and C++ compilers push the parameters onto the stack in reverse order for historical reasons (having to do with making the first parameter to printf, the format string, appear on top of the stack). The first and third parameters are called by value, but the second parameter is passed by reference, meaning that the address of the buffer (indicated by &) is passed, not the contents of the buffer. Then comes the actual call to the library procedure (step 4). This instruction is the normal procedure call instruction used to call all procedures.
The library procedure, perhaps written in assembly language, normally puts the system call number in a place where the operating system expects it, such as a register (step 5). Then it executes a TRAP instruction to switch from user mode to kernel mode and start execution at a fixed address within the kernel (step 6). The TRAP instruction is actually fairly similar to the procedure call instruction in the sense that the instruction following it is taken from a distant location and the return address is saved on the stack for use later.
However, the TRAP instruction is also different from the procedure call instruction in two basic ways. First, as a side effect, it switches into kernel mode. The procedure call instruction does not change the mode. Second, rather than giving a relative or complete address where the procedure is located, the TRAP instruction cannot jump to an arbitrary address. Depending on the architecture, it either jumps to a single fixed location, there is an 8-bit field in the instruction giving the index into a table in memory containing jump addresses, or equivalent.
The kernel code that starts following the TRAP examines the system call number and then dispatches to the correct system call handler, usually via a table of pointers to system call handlers indexed on system call number (step 7). At that point the system call handler runs (step 8). Once the system call handler has completed its work, control may be returned to the user-space library procedure at the instruction following the TRAP instruction (step 9). This procedure then returns to the user program in the usual way procedure calls return (step 10).
In order to finish the job, the user program has to clean up the stack, as it does after any procedure call (step 11). Assuming the stack grows downward, as it often does, the compiled code increments the stack pointer exactly enough to remove the parameters pushed before the call to read. The program is now free to do whatever it wants to do next.
In step 9 above, we said "may be returned to the user-space library procedure" for good reason. The system call may block the caller, preventing it from continuing. For instance, if it is trying to read from the keyboard and nothing has been typed yet, the caller has to be blocked. In this case, the operating system will look around to see if some other process can be run next. Later, when the desired input is available, this process will get the attention of the system and steps 9-11 will occur.
In the following sections, we will look at some of the most heavily used POSIX system calls, or more particularly, the library procedures that make those system calls. POSIX has about 100 procedure calls. Some of the most important ones are listed in "System Calls for Process Management" figure (a), grouped for convenience in four categories. In the text we will briefly look at each call to see what it does.
To a large extent, the services offered by these calls determine most of what the operating system has to do, since the resource management on personal computers is minimal (at least compared to big machines with multiple users). The services include things like creating and terminating processes, creating, deleting, reading, and writing files, managing directories, and performing input and output.
As an aside, it is worth pointing out that the mapping of POSIX procedure calls onto system calls is not one-to-one. The POSIX standard specifies a number of procedures that a conformant system must provide, but it does not specify whether they are system calls, library calls, or something else. If a procedure can be carried out without invoking a system call (i.e., without trapping to the kernel), it will generally be done in user space for reasons of performance. Nevertheless, most of the POSIX procedures do invoke system calls, generally with one procedure mapping directly onto one system call. In a few cases, particularly where various required procedures are only minor variations of one another, one system call handles more than one library call.
Tagskernel mode, personal computer, system calls
- Soft Timers
- Interrupts Revisited
- MEMORY MANAGEMENT
- Message Passing
- Sleep and Wakeup
- Hybrid Implementations / Scheduler Activations
- Implementing Threads in the Kernel
- Process Termination
- Process Creation
- The Java Virtual Machine / Exokernels
- OPERATING SYSTEM STRUCTURE
- The Windows Win32 API
- Miscellaneous System Calls
- System Calls for Directory Management
- System Calls for File Management
- System Calls for Process Management
- The Shell
- Handheld Computer Operating Systems
- Multiprocessor Operating Systems
- WHAT IS AN OPERATING SYSTEM?
- Introduction To Operating System