• Checkpoint Demos
• Some tips for event_wait and event_signal
• Signals, signal handlers, and kernel-mode
• Note about macros and compiler errors

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.

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.

I talked some about signals in lecture, and most of you also learned about 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.

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).