CMSC 23000
Operating Systems

General Information

Course: CMSC 23000
Operating Systems
Instructor: John Reppy Hinds 033
TA: Jon Riehl Hinds 024A
Lecture: MWF 10:30-11:20
Ry 251
Office hours: 
Tuesday 1:30-3:30 MacLab
Thursday 1:30-3:30 MacLab
Mailing list: cmsc23000 at mailman dot cs dot uchicago dot edu
http://mailman.cs.uchicago.edu/mailman/listinfo/cmsc23000

Overview

This course aims to provide an introduction to the basic concepts and techniques used to implement operating systems. The course will involve both paper exercises and substantial programming projects. Students are expected to have taken CMSC15400 and have a working knowledge of the C programming language.

I expect to cover most of the topics from the first 13 chapters of the text. These include concurrent programming, processes, memory management, I/O systems, and file systems. If time permits, we may also discuss security and/or distributed systems. A preliminary syllabus can be found here.

A substantial part of the course work and grade are the two programming projects. The first is a small project that will introduce you to concurrent programming. The second project will involve implementing an operating system for a 16-bit embedded processor.

Note: next year (AY 2006-2007) this course will be offered in the Autumn quarter. Subsequently, it will only be offered every other year (e.g., Autumn 2008, Autumn 2010, ...).

Text books

The main text for the course is
Title: Operating System Concepts
Author: Silberschatz, Galvin, and Gagne
Publisher: John Wiley and Sons, 2005
The current edition is the Seventh, but I believe that the Sixth edition should also be acceptable for the course.

In addition, there is a supplementary text. The programming assignments will be written using the C programming language (specifically, the C99 version). If you do not have a good C manual, we recommend the following:

Title: C -- A Reference Manual (5th Edition)
Authors: Samuel P. Harbison and Guy L. Steele Jr.
Publisher: Prentice Hall, 2002
Errata: www.careferencemanual.com/errata.htm

Grading

Grading for the course will be based on:

Percentage Component
20% Homework assignments
30% Exams
50% Projects

Handouts

The following is a list of the handouts that have been distributed in class with links to PDF files. As necessary, we will post revisions here.

Date Handout
January 4 Handout 1 --- Course information
January 4 Handout 2 --- Programming assignment tips
January 6 Project 1 --- Unix shell
January 13 Slides from Jon Riehl's lecture
January 18 Homework 1
January 26 Project 2 --- RCX memory management
January 27 Handout 3 --- RCX notes (Revised 2006-02-24)
January 27 Homework 2
February 3 Homework 3
February 6 Project 3 --- RCX kernel
February 17 Homework 4
March 1 Project 4 --- RCX kernel

Links

Here are links to some useful online resources.

An introduction to programming with threads

This DEC SRC technical report is a good tutorial for thread programming with mutex locks and condition variables. While it is targeted at Modula-3, the mechanisms are essentially the same as those found in the Pthreads API.

H8/300 Programming Manual

This manual specifies the instruction syntax and semantics for the H8/300 family of micorcontrollers, which includes the RCX processor.

Academic Honesty

The University of Chicago is a scholarly academic community. You need to both understand and internalize the ethics of our community. A good place to start is with the Cadet's Honor Code of the US Military Academy: "A Cadet will not lie, cheat, or steal, or tolerate those who do." It is important to understand that the notion of property that matters most to academics is ideas, and that to pass someone else's ideas off as your own is to lie, cheat, and steal.

The University has a formal policy on Academic Honesty, which is somewhat more verbose than West Point's. Even so, you should read and understand it.

We believe that student interactions are an important and useful means to mastery of the material. We recommend that you discuss the material in this class with other students, and that includes the homework assignments. So what is the boundary between acceptable collaboration and academic misconduct? First, while it is acceptable to discuss homework, it is not acceptable to turn in someone else's work as your own. When the time comes to write down your answer, you should write it down yourself from your own memory. Moreover, you should cite any material discussions, or written sources, e.g.,

Note: I discussed this exercise with Jane Smith.

The University's policy, for its relative length, says less than it should regarding the culpability of those who know of misconduct by others, but do not report it. An all too common case has been where one student has decided to "help" another student by giving them a copy of their assignment, only to have that other student copy it and turn it in. In such cases, we view both students as culpable and pursue disciplinary sanctions against both.

For the student collaborations, it can be a slippery slope that leads from sanctioned collaboration to outright misconduct. But for all the slipperyness, there is a clear line: present only your ideas as yours and attribute all others.

If you have any questions about what is or is not proper academic conduct, please ask your instructors.


Last revised: March 4, 2006.