| Lab number and topic | Due | Weight |
|---|---|---|
| Lab 1: x86 assembly, boot loader | 01/25/12 | 1 |
| Lab 2: Virtual memory | 01/30/12 (part A), 02/03/12 (part B) | 3 |
| Lab 3: Processes/environments | 02/10/12 (part A), 02/17/12 (part B) | 3 |
| Lab T: Multi-threaded programming | 02/24/11 | 2 |
| Lab 4: Multiprogramming and fork | 03/02/12 (part A), 03/09/12 (part B), 03/30/12 (part C) | 5 |
| Lab 5: Filesystems | 04/06/12 | 2 |
| Lab 6: Network driver | 04/13/12 (part A), 04/20/12 (part B) | 4 |
| Lab 7: Final project (mainly) | 04/20/12 (proposals), 04/27/12 (part A), 5/14/12 (part B) | 0.5 (part A), 6.833 (part B) |
A crucial component of the course is the labs. You will implement (the interesting pieces of) a real operating system that will boot on a PC. The operating system is called JOS. (JOS was developed at MIT and has been used in courses at several other schools, including UT.)
JOS is simpler than Linux and Windows Vista, but it includes most key operating systems abstractions, including a bootloader, memory protection, memory relocation, multiprogramming, a rudimentary file system, and a command shell.
JOS can be thought of as an exokernel, where the kernel implements a minimal set of core functionality that safely exports hardware resources to applications. These low-level kernel interfaces may be inconvenient for user processes to use directly, so user processes will make use of a "library operating system" (libos) to abstract these low-level exported resources into more convenient programming abstractions.
Each lab in the series enhances the functionality of your operating system. Each lab builds on the previous one, so it is important that you design, build, and test carefully at each step. Carelessness in early labs will be costly down the road. There are not many lines of code to write on this project; take the time to understand each phase before moving to the next one.
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"). Below are some guidelines.
First, one of the main purposes of the labs is for you to go through the exercise of figuring out how to make the system work. Thus, if the lab is at first confusing even in its instructions, please don't be discouraged; understanding the instructions is part of the work of the lab. Similarly, if your code is failing one of the tests, note that the job of the course staff is not to help your code to pass but to help you to figure out how to solve the problem.
Second, these labs take time, and you're expected to think through both the labs and the replies of the course staff. As an example, if you get a reply from the TA, and then send email 20 minutes later asking a closely related question, that's probably not ideal.
From lab 3 onward, you will have a project partner and code in pair programming style. You must send us email by Friday, February 3, 2012 11:59 PM CST naming your project team.
Below are details.You are responsible for forming a team with someone with whom you will work well. Resolving any problems that arise during the partnership is your responsibility. If you are unable to resolve a serious problem, the teaching staff will arbitrate. But really, it shouldn't come to that.
Your team must follow the pair programming method. In particular, both members of the team must work together to understand the problem, design the solution, enter code, and test the solution. For code entry, one member should type while the other observes, detects tactical coding defects, and thinks strategically about the overall design. You must frequently swap these roles. You might also want to consider the XP strategy of designing your tests before you design your solutions. In general, studies [1, 2] suggest that pair programming works well: (1) counter-intuitively two programmers working together at one keyboard produce about as much functionality as two programmers working apart at two keyboards, (2) the code produced in this manner is of higher quality than individually programmed code, and (3) in an educational setting both team members learn more than they would separately. Note that for this project, these advantages of pair programming over disjoint work are especially likely to apply: it is vital that both team members understand all aspects of the implementation. Also note that the exams will have questions that require detailed understanding of the labs. It will not reflect well if you and your teammate display very different levels of understanding on the exams.
Besides the coding that you do with your teammate, all of the rules about collaboration still apply. You may not discuss code with anyone on any other team, etc.
These labs will be challenging. We hope they will also be very satisfying. We will work to help you meet the challenge. Also, the labs are structured in such a way that you do not have to write a lot of uninteresting "glue" code. 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!
Last updated: Wed Apr 11 17:07:46 -0500 2012 [validate xhtml]