CS 45: Operating Systems, Fall 2008

Schedule | Text | Grading | Projects | Late Work | Integrity | Class Resources
 
Professor: Tia Newhall
Time: 11:30-12:20 MWF
Location: Science Center 264

Office hours: Monday 4-5, Wednesdays 2-3, 249 Sci Ctr

Course Description

This course is a introduction to the theory, design and implementation of operating systems. An operating system is the software layer between user programs and the computer hardware. It provides abstractions (processes, virtual memory, file system, etc.) of the underlying hardware that are easier to program, and it manages the machine's resources (memory, processors, disks, network interfaces, and other devices). We will cover the following topics: processes (including synchronization, communication, and scheduling), memory (main memory allocation strategies, virtual memory, and page replacement policies), file systems (including naming and implementation issues), I/O (including devices, drivers, disks, and disk scheduling), protection and security.

The course projects will be in C. If you do not know C or if it has been awhile since you've programmed in C, I encourage you to look at some C programming references before the start of the semester.

Prerequisite: CPSC 035, experience in C or C++ (usually satisfied by completing CPSC 025 or 033). CPSC 025 or CPSC 033 are recommended.

Required Text

Schedule

The following schedule is tentative; it will be updated as we go along.
I highly recommend doing the week's reading prior to the first class meeting of that week.
WEEK DAY ANNOUNCEMENTS TOPIC READING & ASSIGNMENTS
1 Sep 01   Introduction, Processes Chapt. 1, 3
lab 1
2 Sep 08 add/drop ends (Sep 12) Processes and Scheduling Chapt. 3, 5
3 Sep 15   Sccheduling and Threads Chapt. 5, 4
hw 1
4 Sep 22   Synchronization
QEMU Guide		 Chapt. 6

lab 2
5 Sep 29   Synchronization cont. Chapt. 6
6 Oct 06   Deadlock Chapt. 7
hw 2
lab 3
 

Oct 13

Fall Break
7 Oct 20 Midterm (Wed night 7-9pm) (Oct 22) Memory Management Chapt. 8
8 Oct 27   Mem Mgmt, Virtual Memory Chapt. 8, 9
hw 3
9 Nov 03   Virtual Memory Chapt. 9
hw 4
lab 4
10 Nov 10   File System Chapt. 10, 11
11 Nov 17 no class Friday (Nov 21) File System, Disks Chapt. 11, 12
lab 5
12 Nov 24 Thanksgiving break (Nov 27) I/0 Subsystem
the sounds of disks failing		 Chapt. 13
13 Dec 01   Protection and Security Chapt. 14, 15
hw 5
14 Dec 08   Distributed Systems Chapt. 16
 

Dec 19

Final Exam (9am-noon) room 264 Sci Ctr

Grading

Grades will be weighted as follows:
20%Midterm Exam (Wed. Oct. 22 7-9pm)
25%Final Exam
50%Homework and project assignments
5%Class Participation

Programming Projects

Most of the projects involve modifications to the Linux operating system, and all will be in the C programming language. There are several C language references in the CS Lab that you may use. In addition, there are many on-line C programming references and tutorials here. If you want to buy your own C language reference, here are two recommendations:

We will be using QEMU for Linux kernel projects. See the On-line Resources section for more information about using qemu.

About the CS Lab

The CS Lab (room 240) and the overflow lab (room 238) are open 24 hours a day for CS students to work on their course assignments. When the CS Lab is in use by a class, you should work in the overflow lab. If you do not already have one, you can get a MicroProx tag from Jeff Knerr. The MicroProx tag will allow you entry to the CS Lab and the Science Center after building hours (use the door between Martin and Cornell to get into the building after midnight).

Please read through the"Computer Lab Rules" under the "Introductions" section of the CS help pages.

Collaboration Tools

You should work with a partner on programming projects. To set up your development environment so that you and your partner can access your joint project files while still protecting them from others, see the following: Safe File Sharing for Group Projects.

For Linux kernel projects, you should periodically copy the kernel source code files you modify (just the ones you modify) into your shared project directory, because we do not do nightly backups of the /local directories that will contain your Linux code. Use scp to copy files to/from your Linux VM to your project directory.

In addition, you may want to use some type of revision control software to help you coordinate shared accesses to project files by you and your partner and to allow a way for you to back-up working versions of your code. I'd recommend using CVS. However, RCS is also available on our systems. rsync and scp can be used to copy source code from your VM to your CS Lab account. See my "Collaboration Tools" documentation for more information.

Late Work Policy

Written homework assignments are due at the beginning of class on the due date. Late written homework assignments will not be accepted. However, it is still to your advantage to do written assignments even if you do not turn them in; they help to reinforce your understanding of the lecture material and they are often typical of the types of questions you may see on exams.

Programming assignments will be submitted on-line using cs45handin. You can submit the same assignment multiple times up to the due date using cs45handin. Once you have submitted your solution to an assignment, make sure to keep a copy of it that you will not modify after you submit it (this way if something goes wrong with cs45handin I can use the dates of your solution files to determine when you submitted your solution). Most assignments will require an additional project demo. You will sign up for a demo slot during which you and your partner will run your modified kernel for me with tests that demonstrate that your modifications work as specified.

You and your partner are allowed to use up to 3 late days this semester for turning in programming assignments. However, at most 2 late days can be used on an individual assignment. One day late means turned in before the original time the assignment was due on the next day class meets. For example, if the original assignment is due on Monday before 1am, then if you submit it after Monday at 1am but before Wednesday at 1am it is one day late.

Use late days wisely; once you have used up your late days, I reserve the right to not accept any further late assignments from you, and if I do accept further late assignments from you, you will receive a significant late penalty on them.

CS Dept's Academic Integrity Policy

Under no circumstances may you hand in work done with (or by) someone else under your own name. Your code should never be shared with anyone; you may not examine or use code belonging to someone else, nor may you let anyone else look at or make a copy of your code. This includes sharing solutions after the due date of the assignment. Failure to abide by these rules constitutes academic dishonesty and will lead to a hearing of the College Judiciary Committee. According to the Faculty Handbook: "Because plagiarism is considered to be so serious a transgression, it is the opinion of the faculty that for the first offense, failure in the course and, as appropriate, suspension for a semester or deprivation of the degree in that year is suitable; for a second offense, the penalty should normally be expulsion."

Discussing ideas and approaches to problems with others on a general level is fine (in fact, we encourage you to discuss general strategies with each other), but you should never read anyone else's code or let anyone else read your code. If you are in doubt about some help that you received, then credit the person(s) from whom you got help by citing them in a comment at the top of the file and discuss the situation with your instructor.

For this course, it is fine to help each other with using qemu, with building and booting a Linux kernel, with using debugging tools, with reading and understanding Linux kernel code, and with reading and understanding the assignments. However, you should avoid discussing the details of your solution with anyone other than your project partner, and you should never look at anyone else's code for a solution to a project (or to a similar project). In addition, there are many useful on-line Linux resources of which you should take advantage. However, you should be careful not to use these resources in such a way that it violates the spirit of our Academic Integrity statement. For example, you should not search the WWW for Linux source code solutions to similar problems (I don't know if any exist, but it is possible), nor should you post questions to news groups or mailing lists seeking a solution to the specific problem you are asked to solve. Basically, the solution and code that you submit as your own should be your own. If you are unclear about what type of collaboration is okay and what type is not, ask me about your situation before proceeding.