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.
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 5, 2010 11:59 PM CST, then you are not exercising the pair option, meaning that if you later see fit to "team up" on your own, you will be viewed as cheating, per the collaboration policy.
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: Fri Apr 16 00:41:22 -0500 2010 [validate xhtml]