CS45 Weekly Lab: week 6, 7

Lab 3 Checkpoint, signals, gcc and macros, some lab 3 tips
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 about them in CS31, but here is a little more information about signals, particularly about when signal handler code is invoked:
compiler errors in code with macros
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).