CS 45: Operating Systems, Fall 2011

Schedule | Text | Grading | Projects | Late Work | Integrity | Class Resources
 
Professor: Tia Newhall
Lecture: 11:30-12:20 MWF, room 181 Sci Cntr
Lab: 2:00-3:30, room 256 Sci Cntr
Office hours: 1:00-2:00 Mondays and by appointment, 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 users and the computer hardware. It implements abstractions that are easier to program than the underlying hardware (e.g. processes, virtual memory, file systems), and it manages the machine's resources (e.g. memory, cpus, disk, 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, SSDs and disks, and disk scheduling), protection and security, and some advanced topics.

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 required. CPSC 033 or CPSC 52 recommended.

Required Text

Schedule

This is a tentive schedule. It will be updated as we go.
WEEK DAY ANNOUNCEMENTS TOPIC & REFERENCES INCLASS & ASSIGNMENTS
1 Aug 29   Introduction, Processes Chapt. 1, 3
lab 1
Wed lab
2 Sep 05 add/drop ends (Sep 09) Processes and Scheduling Chapt. 3, 5
Wed lab
3 Sep 12   Sccheduling and Threads Chapt. 5, 4
4 Sep 19   Synchronization Chapt. 6
Wed lab
hw 1
lab 2
5 Sep 26 No class Wed (Sep 28) Synchronization cont. Chapt. 6
Wed lab
6 Oct 03   Memory Management Chapt. 7
practice synchronization problems
 

Oct 10

Fall Break
7 Oct 17 Midterm (Wed night 7-9pm, rm 199 Sci Cntr) (Oct 19) Mem Mgmt Chapt. 7
hw 2
8 Oct 24   Virtual Memory Chapt. 8
lab 3
9 Oct 31   File System Chapt. 9, 10
10 Nov 07   File System, Storage
the sounds of disks failing		 Chapt. 10, 11
11 Nov 14   I/0 Subsystem Chapt. 12
hw 3
lab 4
12 Nov 21 Thanksgiving break (Nov 25) Protection and Security Chapt. 13, 14
13 Nov 28   Advanced Topics
14 Dec 05      
 

Dec 14

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

Grading

Grades will be weighted as follows:
20% Midterm Exam (Wednesday Evening Oct. 19, 7-9pm)
25% Final Exam
50% Labs and Written Homework
05% Class Participation

Labs

Many 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), overflow lab (room 238), and robot lab are open 24 hours a day for CS students to work on their CS course assignments. When the main CS Lab is in use by a class or ninja session, you should work in the robot or overflow labs. Your ID will allow you entry to the CS labs and the Science Center after building hours (use the card reader at the door between Martin and Cornell to get into the building after midnight). Contact Jeff Knerr if you have problems with ID access.

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.

Because we do not do backups of the /local file system, for Linux kernel labs, you should periodically copy the kernel source code files you modify (just the ones you modify) in /local to your private git repository in /home. You can use scp to copy files between 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 git. 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.

Lab 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 it). 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 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 Unix and C utilities and 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, make sure that you do not use these resources in such a way that it violates the spirit of our Academic Integrity statement. For example, you should not search the web for source code solutions to similar lab 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.