To Kernel Mode and Back

interrupt handling is done within the context of the current process, despite that fact that this process is probably unrelated to the interrupt. Exercise 140 Does the Unix scheme impose any restrictions on the interrupt handlers?

9.7.2 To Kernel Mode and Back

The steps of performing a system call were outlined on page 1.3. Here we give some more details. Recall that a process actually has two stacks: one is the regular stack that resides in the stack segment and is used by the user-level program, and the other is the kernel stack that is part of the per-process kernel data, together with the u-area. Making a system call creates frames on both stacks, and uses the u-area as a staging area to pass data from user mode to kernel mode and back. System calls are actually represented by library functions. Thus making a system call starts by calling a normal library function, in user mode. This entails the creation of a call frame on the user stack, which contains the information required to return to the calling context. It may also contain the arguments passed to the library function. The information regarding what system call is being requested, and what argu- ments are provided, is available to the user-level library function. The question is how to pass this information to the kernel-mode system call function. The problem is that the user-level function cannot access any of the kernel memory that will be used by the kernel-mode function. The simplest solution is therefore to use an agreed register to store the numberical code of the requested system call. After storing this code, the library function issues the trap instruction, inducing a transition to kernel mode. The trap instruction creates a call frame on the kernel stack, just like the function- call instruction which creates a call frame on the user stack. It also loads the PC with the address of the system’s entry point for system calls. When this function starts to run, it retrieves the system call code from the agreed register. Based on this, it knows how many arguments to expect. These areguments are then copied from the last call frame on the user stack which can be identified based on the saved SP register value to a designated place in the u-area. Once the arguments are in place, the actual function that implements the system call is called. All these funcitons retrieve their arguments from the u-area in the same way. Exercise 141 Why do the extra copy to the u-area? Each system call function can get the arguments directly from the user stack When the system call function completes its task, it propagates its return value in the same way, by placing it in a designated place in the u-area. It then returns to its caller, which is the entry point of all system calls. This function copies the return value to an agreed register, where it will be found by the user-level library function. 183

9.8 Error Handling