15-410 Expectations

Course objectives

15-410, Operating System Design & Implementation, is a programming-intensive OS class. The core experience is writing a small Unix-inspired OS kernel, in C with some x86 assembly language, which runs on a PC hardware simulator called Simics (and on actual PC hardware if you wish). Work is done in two-person teams, and "team programming" skills (source control, modularity, documentation) are emphasized. Core concepts include the process model, virtual memory, threads, synchronization, and deadlock. The course includes one medium-sized non-textbook reading assignment with a writing component. If you have already completed an implementation-intensive OS class (one based on, e.g., NACHOS), ECE's Embedded Systems class might be a better opportunity for growth. Finally, past experience suggests that 15-410 is a challenging class. Students who successfully complete it will learn a lot, but it will not be easy.

About This Document

This document sets forth our high-level expectations for the class. You must also read the companion document on Policies & Mechanisms.

Textbook

The textbook is Operating System Concepts, by Silberschatz, Galvin, and Gagne. It is available in CMU's bookstore. While the official text will be the new seventh edition (ISBN 0-471-69466-5), you can probably get by with the sixth or even maybe the fifth. We will not cover all of the text, and some topics (such as synchronization) will be taught in a different manner.

You may also find useful the 15-213 textbook, Computer Systems: A Programmer's Perspective; the K&R C book; and perhaps C Traps and Pitfalls. An excellent source of suggestions for programming style and structure is Rob Pike and Brian Kernigan's The Practice of Programming, especially the first few chapters.

Prerequisites

According to the SCS Undergraduate Courses page, the official prerequisite for this class is 15-213 (Introduction to Computer Systems). We expect students to have taken 15-213 before taking 15-410 (be sure to read the Prerequisities section of the Policies & Mechanisms document for further details).

Furthermore, please be aware that this course relies on skills acquired in 15-213. This means you'll be in trouble if much of what was covered there has been forgotten, or if finishing it was a significant struggle. You should recall what a byte is, what a register is, the meaning of "1<<2", the difference between a process and a thread, roughly what goes in a stack frame, what virtual memory is, what a cache is, etc. You should be proficient in C programming on UNIX systems, including the use of make and a source-level debugger such as gdb or dbx. The class will require writing small amounts of x86 assembly language, and debugging your OS will require you to be able to map back and forth between C and assembly language, so it is very important that you are have retained these skills.

Course Activity

While we do not take attendance in class, we expect students to attend lectures. If you miss a lecture, we expect you to arrange for a fellow student who was in class to teach you what you missed by going over the lecture slides with you. When possible, it is probably wise for you to obtain the agreement of a particular fellow student before the class you miss. Our model for the lecture slides is that they support the lecture and can also support a student-led recapitulation, but that they do not replace the lecture.

While some material will not be covered fully by the textbook, the text will expand on some material covered only partially in class. Thus, reading the relevant sections of the text is wise, and some people will find a second or third reading of some sections useful.

In general, most students who do well in the class will attend lectures regularly and read the textbook thoroughly.

We will grade homeworks, a "book report" assignment, several programming assignments, a mid-term exam, and a final exam.

In slightly more detail:

Homework assignments

Homework assignments are individual assignments designed to reinforce class material through design, analysis, restatement, or simple practice. Although each student should do his/her own homework, students are certainly encouraged to discuss the course material related to the homework to develop a better understanding.

Team Projects

Projects (other than the first two) are designed for two person teams. When choosing a partner, try to ensure that the relationship will last for the remainder of the semester. We will allow changes if the situation merits it and if alternative partners are available. While some people end up working by themselves, we actively discourage this and generally don't view it as a reason for relaxed deadlines or grading.

Both partners should work cooperatively on the design, implementation, and testing of their solutions.

The programming assignments, especially the kernel assignment, are not easy. It is far from unusual for a single one-line bug to take two days to track down. You should plan to finish each project 10%-20% early.

Exams

The exams may cover any material covered in the course. This includes the material from the lectures, from the assigned sections of the textbook, from the additional reading assignments handed out, from the programming projects, or from the homework.

Team Programming

Most of the programming effort will be in a team-programming context, to give you experience with the design strategies, coding standards, documentation practices, source control techniques, and people skills you are likely to need in both industry and academia. Here we differentiate between team programming and software engineering in that we will not cover requirements analysis, release staging, defect management, and other life-cycle issues.

You may experiment with various development styles. Some students explore "Extreme Programming", and others have had good experiences with Pair Programming (Williams & Kessler).

You should probably discuss your committment to the class with potential partners. For example, if it is spring semester and you are planning to graduate, a first-year drama student auditing the class might not make the best partner for you.

Grades

Our overall expectation on grades is:

C

All parts of problem addressed

B

Solution is complete, stable, robust; no major design flaws, etc.

A

Excellent: design is clean, documentation is complete, error handling and logging are good. Probably one or more "good-quality" algorithms are used (as appropriate); it should be credible that somebody might want to re-use some of your code; often you will have done a little bit more than what we asked in a couple of areas.

Academic Conduct

In general, collaboration is good when it furthers genuine learning and bad when it doesn't. Meanwhile, plagiarism (using the work of others without giving them appropriate credit) is definitely bad. This principle can often help you decide between good collaboration and bad collaboration: if you would feel bad about accurately giving credit for part of your program, then it probably shouldn't have been created however it was. Another good rule is that if you're not sure whether something is ok, you should ask the course staff.

Also, in general, we expect you to behave honestly and according to high standards of academic conduct.

Reminder About This Document

This document sets forth our high-level expectations for the class. You must also read the companion document on Policies & Mechanisms.

Acknowledgements

Ideas (and even some text) were stolen from Greg Kesden's 15-412 syllabus and Randy Bryant & Hui Zhang's 15-441 syllabus.

[Last modified Sunday August 28, 2005]