| Lab number and topic | Due | Weight |
|---|---|---|
| Lab 1: C basics | 01/22/13 | 1 |
| Lab sh: System calls and process control | 01/28/13 | 1 |
| Lab 2: Multi-threaded programming | 02/04/13 (part A), 02/08/13 (part B) | 4 |
| Lab 3: x86 assembly, boot loader (JOS) | 02/15/13 | 2 |
| Lab 4: Virtual memory (JOS) | 03/01/13 (part A), 03/08/13 (part B) | 4 |
| Lab 5: Processes/environments (JOS) | 03/22/13 (part A), 03/29/13 (part B) | 4 |
| Lab 6: Multiprogramming (JOS) | 04/08/13 | 2 |
| Lab 7: File systems | 04/19/13 | 4 |
| Lab 8: HTTP proxy | 04/29/13 (part A), 05/06/13 (part B) | 3.5 |
A crucial component of the course is the labs. You should expect these labs to require you to spend substantial time programming.
The labs are in two categories. Some of the labs (on threading and file systems) are "standalone." Others are cumulative: you will implement functionality in the context 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.)
Though simple, JOS includes many key operating systems abstractions, including a bootloader, memory protection, memory relocation, and multiprogramming. 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 make use of a "library operating system" (libos) to abstract these low-level exported resources into more convenient programming abstractions.
In the JOS portion of the labs, the labs build on one another. Thus, it is important that you design, build, and test carefully at each step. Carelessness early will be costly later. 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 a system work. 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! 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 a TA, and then send email 20 minutes later asking a closely related question, that's probably not appropriate.
All labs except lab 1, lab sh, and lab 3 will be coded in pair programming style. You must send the staff email by Friday, January 25, 2013 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. 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: Sat May 11 12:35:54 -0500 2013 [validate xhtml]