CS372H 2009 Project Information

Overview

The project for this class is to construct a real operating system that will boot on a PC. This operating system is simpler than Linux, OS X, Solaris, or Windows 7, but it includes most key operating systems abstractions including a bootloader, memory protection, memory relocation, multiprogramming, a rudimentary file system, and a command shell.  The operating system architecture 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.

The project is divided into a series of labs, each of which 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, so take the time to understand each phase before moving to the next one.

You will work on this project in teams of two. You are responsible for forming a team with someone with whom you will work well, and resolving any problems that arise during the partnership is your responsibility. If you are unable to resolve a serious problem, the instructor will arbitrate.

Your team must follow a pair programming methodology. In particular, both members of the team must work together to understand the problem, design your solution, enter code, and test your solution. For code entry, one member should type while the other observes, detects tactical coding defects, and thinks strategically about the overall design. These roles must be frequently swapped. 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 be aware that the exams will have questions that required intimate knowledge of the project.

This project will be challenging. We hope it will be very satisfying. The instructor and TA will work to help you succeed on this challenging project. Although the scope of the project is ambitious, we will provide a framework to guide your efforts and to ensure that you don't have to spend a lot of time building uninteresting "glue" code. Our hope and expectation is that everyone that works hard on this project will succeed. If you have other ideas for improving the project, please let us know. Good luck!

Schedule


Lab
 Objective
 Due
 Relative Weight
Lab 1 Bootloader
 Understand the lab development environment. Understand how initialization works. Understand linking, loading, position-dependent code, and position-independent code.
Jan 30
 10
Lab 2 Virtual memory
 Build a 2-level page table and a free-space list.
 Feb 13
 15
Lab 3A Processes/Environments
 Create user-level process. Develop interrupt/trap handlers.
 Feb 27 (part A)
Mar 7 (part B)
 20
Lab T Multi-threaded programming
 This short lab will focus on basic multi-threaded programming techniques. This lab is not integrated into the main "build an operating system" project, but it helps you develop an essential, practical skill that you will need for real-world programming projects.
 Mar 11
 5
Lab 4 Multiprogramming and Fork
 Create multiple user-level processes. Develop system calls to allow communication between a user-level process and the kernel (and between user-level processes.) Implement a user-level page-fault handler. Implement an efficient copy-on-write fork().
 Apr 3 (A, B), Apr 10 (C)
 20
Lab 5 Exec
 Access a rudimentary file system to allow a process to exec() a program stored in the file system
 Apr 24
 20
Lab 6 Shell
Construct unix-like shell with pipes and redirection.
 May 8
 10