[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