Week 6: Lab 3 Checkpoint demo
In order to leave time to help you with lab 3 questions, each
group should quickly demo to me just their checkpoint functionality
(each group gets ~3 minutes to do so).
Log in, get your VM up and running, and I'll come around to see
group's checkpoint demo.
As you wait for me to get to your group, work on implementing new
functionality in the code or on test code and/or come up with a list of
any questions you may have about lab 3.
After seeing everybody's demo, I'll answer questions and help groups
with any problems they may be having.
Some tips for adding blocking/unblocking functionality to Lab 3
I think that for this part it will be very helpful to look at
existing kernel source code
that uses wait queues to help you figure out how to implement
similar code. Not every example you find will fit with how you
will want to implement similar functionality, so you may have to
hunt around a bit to find code that is closer to what you want to
do. Also, look in wait.h for functions and macros that you can use,
and make sure you understand what a macro is doing before using it; some
may be useful and some may not depending on the context in which you
are using wait queues. Additionally, as a rule of thumb do not
use functions with underscores in front of them (there usually is another
wrapper function around these that is more appropriate to use).
As you add support for blocking processes on Events and waking up
blocked processes on events, think about where a blocked process
continues after being woken up.
Signals and kernel-mode
I talked some about signals in lecture, and most of you also learned
them in CS31, but here is a little more information about signals,
particularly about when signal handler code is invoked:
- Signals are asynchronous software interrupts (the are not traps, which
are synchronous software interrupts, and they are not hardware interrupts
which are asynchronous but triggered by hardware not software).
- A process can have multiple signals pending (a bit vector in the PCB
is used to keep track of this).
- Signals are "caught" and "handled" by default signal handler code in
the kernel, or by user-level handlers registered on some signals.
- Some signals can be "blocked" (the process will ignore them), but not
all signals can be blocked (SIGKILL for example).
- Signal handler code runs immediately if the process is in user-mode.
However, if the process is in kernel-mode, the signal handler
does not immediately run. Instead, pending signals are handled right before
the process returns from the system call; you do not need
to worry about signal handler code interrupting your system call code
until it returns.
compiler errors in code with macros
are expanded in the first phase of compilation
(the phases of compilation
Multi-line macros replace a single line of your C source code with
multiple lines of code. The compiler then compiles this #define expanded
code, which means that the source code line numbers in your .c file
may not match the source code line number in the expanded version of
the code that the compiler compiles. As a result, you may get some
odd errors that don't seem to point you to the right line of code. This
is often an error in how you are using a macro, or an error in your
code after a use of a multi-line macro where the line numbers are off
by the number of lines in the macro.
All the macro definitions are in .h files in the linux
source code, many in files in the include/linux/ subdirectroy. You
can look at these definitions to see if they are single or multi-line.
It is also good to look at the macro definitions to get some
understanding of what they do and how to call them (and if they are
useful or not for your situation).