Link Search Menu Expand Document

CS6640: Labs

LabTopicDue
Lab1Setup and hello world09/13/2023, 23:59
Lab2User-level Threading09/27/2023, 23:59
Lab3Kernel scheduler and MLFQ10/11/2023, 23:59
Lab4Syscall, Exception, and Memory protection10/24/2023, 23:59
Lab5Virtual memory11/20/2023, 23:59
Lab6File system12/05/2023, 23:59

Spending your time on labs (and start early!)

This course is about implementing operating systems. Your job in this course is to implement one by finishing the above labs. You should expect spending most of your course time working on these labs.

Reading is part of the labs

Different from “normal programming”, coding in OS kernels requires a good understanding of CPU, memory, compilers, linkers, peripheral devices—basically everything about a computer! Therefore, you need to spent substantial time to read lab instructions, corresponding documents, and the provided skeleton code to understand what to do in labs. Indeed, one of the main purposes of the labs is for you to go through the exercise of figuring out how an OS (conceptually) works. Thus, if a lab is at first confusing even in its instructions, please don’t be discouraged; understanding the instructions is part of the work of the labs!

Debugging is part of the labs

Debugging is hard. Debugging OS kernel is even harder. By our experience, more than 80% of tricky bugs come from “silly” errors, for example, variable name typos, forgetting to re-compile the code, copy-pasting code but forgetting to update all, incorrect type conversions, misunderstanding of C operator precedence and associativity, misreading of documents and manuals. So, when encountering an error, you should first think thoroughly about why this happened, instead of immediately opening your gdb or randomly printing debug messages. We found it useful to re-examine your code and write down the expected behaviors first, and then start your debugging. [Aside: sometimes it is easier to start over than to debug a weird bug; of course, take this with a grain of salt ;-)]

Asking for help

We (the course staff) are happy and even eager to help on the labs. When should you ask for such help? Mainly, you should use your judgment (the rough answer is: “when you’re actually stuck”). But, asking for help every 20min is clearly not a good idea.

When asking for help, you should describe the problem (what you’ve observed and why this is a problem) and your initial analysis (what could be the root cause of the problem). Please do not expect TAs will help debug your code because debugging is part of your job (see the above point).

A final note

Some of these labs will be challenging. We hope they will also be very satisfying. We will work to help you meet the challenge. Our hope and expectation is that everyone who works hard on the labs will succeed. If you have ideas for improving the labs, please let us know. Good luck!