CS 372H: Labs

Assignments

Overview

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 a lot of lines of code to write on this project; take the time to understand each phase before moving to the next one.

A final note

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!

Pair programming option

You have a one-time choice about whether to code in pairs or individually. Please read the following very carefully; failing to follow these directions could get you into very serious trouble. In particular, if you do not send us email by Friday, February 4, 2011 11:59 PM CST, then you are not exercising the pair option, meaning that if you later decide to "team up" on your own, you will be viewed as cheating, per the collaboration policy.

• Lab 2 you are doing individually.
• You have a one-time choice about whether to code in pairs from lab 3 onward. But it is all or nothing: either you join the "pair track", and then every single assignment must be done in pairs, or you stay on the "individual track", and then you are not allowed to share code. There is no middle ground.
• If you choose the pair option, you must do the following:
  • Send the teaching staff email by Friday, February 4, 2011, 11:59 PM. This email must contain the two names of your team members.
  • Stay in this team throughout the semester. You cannot later split up, form a new team, etc. Any of these things constitutes cheating.
  • Continue to follow the collaboration policy strictly, with the sole exception that you obviously can and should discuss code with your partner.
  • Note that handing in an assignment late depletes both of your slack hours. That is, if you hand in the assignment 6 hours late, each of you gets 6 slack hours deducted. More generally, once you pair, your team has a number of slack hours equal to the minimum of the two team members' slack hours. If you deplete your slack hours, you will lose points as per the late policy.
• If you do not send us email by this Friday night, you are coding individually for the remainder of the semester. Please note very carefully what this means: it means that if you don't send us email and then do code in a pair, both of you are violating the collaboration policy. That could have very ugly consequences.

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.

Last updated: Thu May 19 05:16:14 -0500 2011 [validate xhtml]