[OSy] System calls
Martin Decky
decky at d3s.mff.cuni.cz
Mon Jan 9 18:41:43 CET 2017
Dear all,
while examining the solutions of the 5th assignment I have noticed that
not all people fully understand the basic concept of system calls.
System calls resemble, in many ways, plain function calls, but they are
not function calls. It is not possible to simply call say the kernel
sys_thread_create() function that implements the system call kernel
business logic from the user space thread_create() function. Note that
the kernel space and the user space are entirely separate worlds that do
not directly link with each other.
In order to "bridge" these separate worlds, the user space must somehow
"trigger" the kernel when it requires the kernel to do something (i.e.
process the system call). This "triggering" means deliberately causing
an exception that the kernel then handles. There are many ways how to
trigger an exception, but most CPU architectures provide a special
instruction for the very purpose of executing a system call.
On MIPS, this instruction is called "syscall" and the SYSCALL0,
SYSCALL1, etc., macros in Kalisto generate this instruction (see
user/librt/syscall.h). The exception triggered by the "syscall"
instruction is then handled by the kernel and this is how the system
call gets processed. The system call arguments are transferred via
registers similarly to a regular function call on MIPS.
If you still cannot wrap your head around this mechanism, I suggest you
compile Kalisto with your own user space process with empty main(). The
run-time will eventually run exit(). When single-steping it, you will
clearly see how the "syscall" instruction within exit() is executed, how
the control flow is passed to the kernel and how the kernel processes
the SYS_EXIT system call.
If you are still puzzled, let us know.
M.D.
More information about the NSWI004
mailing list