CS45 S'14 Swarthmore

Class Information

Professor: Tia Newhall
Office: Science Center 249
Phone: (610) 690-5637
Office hours: Wednesdays 2-4 and by appointment

Class: 10:30 MWF, Sci Cntr 183
Lab A Time: 1:15-2:45 M, Sci Cntr 240
Lab B Time: 3:00-4:30 M, Sci Cntr 240

Required Text: Operating Systems Concepts, 9th Edition
by Abraham Silberschatz, Peter Baer Galvin, Greg Gagne
ISBN: 978-1-118-06333-0
The text is also available as an ebook rental ($59.50) from CourseSmart, or from Wiley Custom Select (this one may be downladable).
A copy of the textbook is also on reserve at Cornell Library.

Link to class Piazza page

Course Overview:

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, distributed systems and other advanced topics. Prerequisites: CPSC 35 and CPSC 31 required.

Schedule

This is a tentative schedule. It will be updated as we go.

WEEK	DAY	ANNOUNCEMENTS	TOPIC & READING	ASSIGNMENTS
1	Jan 20		Introduction and Processes Ch. 1-1.5, 3 (read) Ch. 1.6-1.13, 2 (skim)	Mon lab lab 1
2	Jan 27	Add/Drop Ends (Jan 31)	Processes, Threads, Scheduling Ch. 3, 4, 6	Mon lab
3	Feb 03		Scheduling and Threads Ch. 4, 6, 2.3 (system calls)	Mon lab lab 2 homework 1
4	Feb 10		Scheduling, Synchronization Ch. 6, 5	Mon lab homework 2
5	Feb 17		Synchronization cont. Ch. 5	Mon lab lab 3
6	Feb 24		Synchronization, Memory Management Ch. 5, 8	Mon lab inclass
7	Mar 03	No class Friday (Mar 07)	Memory Management, Virtual Memory Ch. 8, 9	Mon lab homework 3
	Mar 10	Spring Break
8	Mar 17		Virtual Memory Ch. 8, 9	Midterm Information
8	Mar 20	Midterm Exam (7-9pm) room 199 Sci Ctr
9	Mar 24	Last Day CR/NC/W (Mar 28)	Virtual Memory Ch. 8, 9	Mon Lab lab 4
10	Mar 31	No class Friday (Apr 04)	Storage, I/O Subsystem Ch. 10, 13.2-13.4 the sounds of disks failing	Mon lab
11	Apr 07		File Systems Ch. 11, 12	Mon Lab lab 5 homework 4
12	Apr 14		File Systems, Protection Ch. 11,12 (skim 14)	.
13	Apr 21		Security Ch. 15	Mon Lab
14	Apr 28		Distributed Systems Ch. 17	homework 5
	May 16	Final Exam (9am-noon) room 183 Sci Ctr

Grading

Grades will be weighted as follows:

25% Midterm Exam (Thurs March 20, 7-9pm)

30% Final Exam

40% Labs and Written Homework

05% Class Participation

Labs

Most of the labs will be written in the C programming language. 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. If you want to buy your own C language reference, here are two recommendations:

C Programming Language, 2/e, by Brian W. Kernighan and Dennis M. Ritchie
Kernighan and Ritchie are the authors of the C programming language, so as you may expect, this is a very good and complete C language reference.
A Book on C: Programming in C, by Al Kelley and Ira Pohl
This is a good reference with a slightly more user-friendly introduction to programming in C.

About the CS Lab

I encourage you to work in one of the CS labs when possible (vs. remotely logging in), particularly when working with a partner. The CS labs (rooms 240, 256 and 238) are open 24 hours a day, 7 days a week for you to use for CS course work. With the exception of during times when a class, or a class lab or ninja session is scheduled in 240 or 256, you can work in one of the CS labs on your CS course work anytime. The overflow lab (238) is always available. The CS lab resources are for CS course work. Please review the CS Lab Rules and CS User Rules about appropriate use of CS labs.

Accessing the CS labs after hours: Use your ID to gain access to the computer labs at nights and on the weekends. Just wave your ID over the microprox reader next to the lab doors. It should display a green light and beep when unlocked, just push on the door handle to get in (the door knob will not turn). If the green light doesn't go on, then we need to enter your id number into the system. email local-staff@cs.swarthmore.edu if you have problems with this. If the building is locked, you can use your ID to enter the door between Martin and Cornell library.

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. 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. See my "Collaboration Tools" documentation for more information.

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.

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 (note: this has a very different interface from the handin scripts used in 21, 31, and 35). 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 solution for me with tests that demonstrate your solution is correct and robust.

You are allowed to use up to 3 late days this semester for turning in lab assignments. However, at most 2 late days can be used on an individual assignment. One day late means up to 24 hours past the original due date of the assignment; 24 hours and 1 minute counts as two late days. If you switch lab partners, your late days stick with you (i.e. you do not get to start over, nor do you get to count late days using a new partner's count that is different from your own.)

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.

Tips for Success

Attend class and actively participate in class.
The primary introduction to course material is through class lecture. Additionally, we often do exercises during class. Showing up is necessary, but not sufficient to success in the course: ask questions, participate in class discussions and in class activities, and take notes.
Read the material before you come to class.
Don't worry about total comprehension, but at least get a feel for what we will be covering that week. If you have some understanding of the material coming into class, it will be easier for you to follow the lecture and to ask questions during class. See my tips for reading CS textbooks for guidelines on getting the most out of assigned readings.
Start the lab assignments early.
I realize this one is not always easy to do, but if you can get in the habit of doing this, you will be much better off. As the labs get longer and more difficult, starting early will give you plenty of time to mull over the lab problems even when you aren't actively writing your solution.
Practice, practice, practice.
The only effective way to learn the material and pass the exams is to consistently do the labs, and to practice example problems presented in class and in the book. Forming study groups to go over practice problems and to review lecture and reading notes is a great way to prepare for exams.
Seek help early and often.
Because course material builds on previous material, it is essential to your success in this class that you keep up with the course material. There are a lot of sources of help: ask questions during lecture; ask your classmates (make sure you have read the "Academic Integrity" section below first); get help during lab sessions; and come to office hours.
Take hand written lecture notes.
In lecture the professor often draws diagrams on the board, some of which you will need to reproduce. Taking notes with paper and pen (vs. on the computer) will allow you to copy these diagrams.

Academic Integrity

The CS Department's Academic Integrity Policy:
Academic honesty is required in all your work. 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, but is not limited to, obtaining solutions from students who previously took the course or code that can be found online. You may not share solutions after the due date of the assignment.

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. All code you submit must be your own with the following permissible exceptions: code distributed in class, code found in the course text book, and code worked on with an assigned partner. In these cases, you should always include detailed comments that indicates on which parts of the assignment you received help, and what your sources were.

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."

For this course, it is fine to help each other with using VirtualBox, 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. If you think you may have violated this policy, come talk to me right away about your situation.

Accommodations Statement

If you believe that you need accommodations for a disability, please contact Leslie Hempling in the Office of Student Disability Services (Parrish 130) or (e-mail lhempli1 AT swarthmore DOT edu) to set up an appointment to discuss your needs. Leslie Hempling is responsible for reviewing and approving disability-related accommodation requests. As appropriate, she will issue students with documented disabilities an Accommodation Authorization Letter. Since accommodations require early planning and are not retroactive, please contact her as soon as possible. For details about the Student Disabilities Service and the accommodations process, visit the Disability Services website. You are also welcome to contact me privately to discuss your academic needs. However, all disability-related accommodations must be arranged through Leslie Hempling in the Office Of Student Disability Services.

Resources

Below are some resources and links that may be helpful to you (I will add more over the course of the semester).

Virtual Box guide for CS45 students
cs45handin
C Programing (programming, C style guide, compiling, debugging, ...)
My Help Pages and Links (Unix and Linux, gdb, git, C, ...)
CS Department's Help Pages
remotely connecting to CS
Useful Unix commands
Tools for examining system state

Operating Systems

CS45: Spring 2014

Announcements