finished lec 8 notes
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Fri, 29 May 2009 17:31:39 +0000 (13:31 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Fri, 29 May 2009 17:31:39 +0000 (13:31 -0400)
lec08-0528.tex

index 3edff36..6c1fec9 100644 (file)
@@ -8,8 +8,52 @@
 \maketitle
 
 \section*{Lecture 8 -- System Calls, Exceptions, Interrupts}
-In userspace, system calls look just like procedure calls
+In userspace, system calls look just like procedure calls This allows them to
+be portable. Otherwise our programs would have to include machine-specific
+instructions, like \texttt{syscall} in MIPS. The library just provides wrappers
+around the system calls for our convenience. See \texttt{lib/libc/syscalls.S}.
 
-\subsection*{Deadlock Detection and Prevention}
+\subsection*{\texttt{syscall}}
+The system call instruction jumps directly to the addressa where the exception
+handler waits. It also does some special things for us, such as turning off
+interrupts so that a trap frame can be saved to the kernel stack, etc. This is
+doable thanks to the \texttt{k0} and \texttt{k1} special registers. By
+convention, user programs are not allowed to assume these will be preserved
+by system calls. The trap frame saves all of the state of the CPU from the
+application thread's execution. Later, \texttt{mips\_trap()} turns interrupts
+back on, and the kernel starts doing its work. The kernel may be running, but
+it can still be preempted at any time. The trap frame is used to
+restore state for the application thread when the system call is done. The
+special \texttt{ref} instruction is the complement of \texttt{syscall} and
+turns interrupts back on, among other things. Notice that the kernel places
+the return values directly into memory where the trap frame was saved -- it
+can't set registers, because the current register state belongs to the
+kernel, not the application thread.
+
+Also note that this means each thread has two stacks, one for application code
+that runs without special privileges, and one for when the kernel is executing
+privileged code on behalf of the thread. One of the benefits of this is for
+protecting sensitive data from snooping application (e.g. things that may be
+saved into stack frames but not zeroed out), and to simplify memory management.
+Stacks can overflow, so if an application stack is nearly full and calls a
+large system call, then the kernel's stack frames may overflow that stack. By
+maintaining and managing it's own stack, the kernel doesn't have to worry about
+overflowing the application thread's stack.
+
+\subsection*{Exceptions}
+The whole process of servicing an exception is almost identical to that of a
+system call. The difference is that exceptions are unintentional, mistakes that
+the program makes, such as accessing the wrong part of memory or dividing by
+zero. Each kind of exception has a unique code, see
+\texttt{arch/mips/include/trapframe.h} for the meaning of each one. The kernel
+look at this value to see what to do next. It'll decide what to do based on
+what generated the exception, or whether it was a system call that jumped into
+the exception handler, or perhaps a hardware interrupt. 
+
+\subsection*{Interrupts}
+Hardware causes interrupts. They can happen inside of the kernel. There is no
+problem with this though, the exception handler will save a trap frame of the
+kernel's state, and then go about business as usual. We can see in the
+exception handler that it checks to see if it was already in the kernel.
 
 \end{document}