System Calls
If you are a programmer, you probably know what a system call
is and have
used them many times in your programs. If you are not a programmer, you may not
know what it is, but you still use them thousands of times a day. All
"low-level" operations on the system are handled by system calls,
including such actions as reading from the disk or printing a message on the
screen. System calls are the user's bridge
between user space and kernel
space.
This also means that they are the bridge
between a user applicationand the system
hardware.
Collections of system calls are often combined into more complex
tasks and put into libraries. When using one of the functions defined in
a library, you call a library function or make a library
call. Even when the library routine is intended to access the hardware, it
will make a system call
long before the hardware is touched.
Each system
call has its own unique identifying number. The kernel
uses this number as an
index into a table of system call
entry points, which point to where the system
calls reside in memory along with the number of arguments that should be passed
to them.
When a process makes a system call, the behavior is similar to
that of interrupts and exceptions. Like exception handling, the general
purpose registers and the number of the system call
are pushed onto the stack.
Next, the system call
handler is invoked, which calls the routine within the
kernel that will do the actual work.
Although there are hundreds of
library calls, each of these will call one or more systems calls. In total,
there are about 150 system calls, all of which have to pass through this one point
(referred to as a "call gate") to ensure that user code moves up to the higher privilege level at a
specific location (address)within the
kernel. Therefore, uniform
controls can be applied to ensure that a process is not doing something it
shouldn't.
As with interrupts and exceptions, the system checks to see
whether a context switch
should occur on return to user mode.
If so, a context
switch takes place. This is possible in situations where one process made a
system call and an interrupt
occurred while the process was in kernel
mode. The
kernel then issued a wake_up() to all
processes waiting for data from the hard disk.
When the interrupt
completes, the kernel
may go back to the first process that made the system
call. But, then again, there may be another process with a higher priority.
|