@c FIXME: base system doesn't do anything. Debugger sucks.
However, there's a lot of magic going on in some of this code, so you
should compile and run the base system to see a simple test of the
-code. You should trace the execution using your favorite debugger to
-get a sense for what's going on.
+code. You should read through the source code by hand to see what's
+going on. If you like, you can add calls to @code{printf()} almost
+anywhere, then recompile and run to see what happens and in what
+order.
When a thread is created, you are creating a new context to be
scheduled. You provide a function to be run in this context as an
thread needs to wait for another thread to do something.
The exact mechanics of a context switch are pretty gruesome and have
-been provided for you in @file{switch.S} (this is 80@var{x}86
-assembly; don't worry about understanding it). It involves saving the
+been provided for you in @file{threads/switch.S} (this is 80@var{x}86
+assembly; don't worry about understanding it). It involves saving the
state of the currently running thread and restoring the state of the
thread we're switching to.
@c FIXME
@section Problem 1-4 Advanced Scheduler
Implement Solaris's multilevel feedback queue scheduler (MFQS), as
-explained below, to reduce the average response time for running jobs
-on your system.
-@c FIXME need link
+explained in this @uref{mlfqs.pdf, , PDF} or @uref{mlfqs.ps, ,
+PostScript} file, to reduce the average response time for running jobs
+on your system.
Demonstrate that your scheduling algorithm reduces response time
relative to the original Pintos scheduling algorithm (round robin) for