Fall 2017 :: CSE 306 — Operating Systems

Course Description

This course is an in-depth study of important concepts and techniques found in modern computer operating systems. The main objective is to turn operating systems from "magical black boxes" that somehow make computers work to well-understood software systems that you can debug, dissect, improve or even design from scratch.

To this end, we will consider operating system design and implementation along four main dimensions, namely, services, abstractions, architectures and algorithms: services that a typical operating system should provide to user applications, abstractions that operating systems expose in order to provide these services, and the different software architectures and algorithms that they internally use to implement those abstractions.

The course takes an in-depth look at classical OS issues such as virtual memory, file systems, networking, multiprocessor support, isolation, security and scalability. We will also take an introductory look at some of the more recent trends in operating systems research and practice such as virtual machines, advanced file systems, etc. Textbook readings are supplemented, where appropriate, by papers from the research literature.

An important part of the course is the case study of an educational, but real, operating system called xv6. Students study the source code for this operating system, and do programming exercises and projects that involve modifying xv6 and implementing new features in it.

Prerequisites

CSE 219 or CSE 260; CSE 320 or ESE 380; CSE Major or ECE major; and a working knowledge of the C language.


Course Information

  • Time: Tue & Thu 2:30 - 3:50 pm.
  • Location: Frey Hall, Room 217.
  • Instructor: Nima Honarmand, New CS Building, Room 339. Office Hours: Tue & Thu 4:00 - 5:00 pm, or by appointment.
  • TA: Babak Amin Azad. Office Hours: Mon & Wed 5:30-7:00 pm, or by appointment. Office Hours Location: Old CS Building, Room 2217.
  • Newsgroup: "General Discussions" Forum on Blackboard. Blackboard is the main venue for all class-related discussions and announcements.

Evaluation

Students will be evaluated based on their performance in exams and lab assignments.

Exams

There will be two exams in this course: a midterm exam, to be held in-class, and a final exam, which will be held during Finals Week at the officially scheduled date/time. See the course schedule for specific exam times and locations. Both exams will be closed-everything.

There will be an in-class midterm on Tuesday, October 17, 2017. Please mark your calendars now. If you have a conflict with the midterm, tell the instructor during the first two weeks of class, and we will schedule a makeup for a time before the exam is given to the rest of the class.

Lab Assignments

Lab assignments are explained in detail here. There will be 5 assignments including both kernel-mode and advanced user-mode programming. Some lab assignments include optional "Challenge Problems" which you can do for extra points.

Working in Teams

You may work on your lab assignments in groups of up to two students. Do not discuss code with anyone other than your teammate and the course staff. See the collaboration policy below.

Late Hours

You get 72 free late hours during the semester. They are intended to let you manage incidents, holidays, travels, other deadlines, conferences, etc. without having to explain to the course staff. Use them wisely! After they are used up, each hour of late submission will cost 2% of the assignment grade.

Exemptions to the lateness rule will be allowed in three cases:

  1. Illness, which has to be documented by a doctor and approved by the university.
  2. Death in the immediate family.
  3. Accomodations for students with disabilities, as prescribed by the university.
No extensions will be given for any other reason.

Grading

  • Lab assignments: 60%
  • Midterm exam: 20%
  • Final exam: 20%

The guaranteed letter grades for the course are as follows: [A, A-, B+, B, ..., D, F] = [85, 80, 75, 70, ..., 45, <45]. A curve might be applied on top of this, at the instructor's discretion, to improve the letter grades.


Course References

There is one required textbook for the course which is freely available online, thanks to Professors Remzi Arpaci-Dusseau and Andrea Arpaci-Dusseau from University of Wisconsin:

The following three books are highly recommended as supplemental references for the course. The first one is closely related to our frequent discussions of the Linux kernel. The second one is an authoritative reference on advanced systems programming in Unix environments. The third one is the world-famous K&R book on the C programming language.

The following are some other useful references. You can find them on Amazon or other online book stores. Some are also available for free on campus through Safari online. Also, make sure to check the university library for hard or electronic copies of these and other books that you may need. If not already available, you can ask the library to purchase them.

Additional readings will be assigned as needed from materials that are available online or from the library. In addition, you can find a list of useful references and reading materials here.


Academic Integrity

Collaboration vs. Cheating

In the labs you may work with a partner. If you work alone, you submit your own work. If you work in a team, you will submit your assignments jointly with your team. Whether or not you work in a team, you may discuss the programming assignments with anyone you like in general terms, but you may not share code with anyone other than your partner. The code you and your partner submit must be your own work, and only your own work. Any evidence that source code has been copied, shared, or transmitted in any way between non-partners (this includes using source code written by others in previous semesters, or at other universities!) will be regarded as evidence of academic dishonesty.

Handing in someone else's work is expressly forbidden.

Some more specific guidelines for the labs:

  • You should not discuss actual code, in any form. You may not discuss code at a white board. You may not help each other debug your code.
  • You must write down the names of people with whom you discussed the assignment and what you discussed with them. If student A gets an idea from student B, both students must write down that fact and also what the idea was.
  • You must further acknowledge any other contributions (for example, ideas from Web sites or other sources).
  • Take suitable precautions to protect your written work. For instance, do not leave printouts lying around, lest you be suspected as an accessory to cheating.
  • You may not look at code from previous years of this course.
  • You may not look at code from similar courses at other universities.
  • Do not show another person (other than the instructor or TA) your work until after the semester end. Because we have a very liberal lateness policy, you should not assume that another student has completed an assignment after the deadline.

Note that the course staff will use tools such as MOSS to detect cheating. These tools are very good at comparing large sets of programing assignments and correlating those that have a shared code basis, even if the code has been changed significantly!

You are welcome to use existing public libraries in your programming assignments (such as public classes for queues, trees, etc.) You may also look at operating systems code for public domain software such as Linux. Such activities qualify under approved collaboration practices, and you are welcome to take advantage of them. Note that you must cite and acknowledge those sources properly. Not doing so constitutes academic plagiarism, and will not be tolerated.

We are very serious about not tolerating academic dishonesty. When I am able to establish that academic dishonesty has occurred, I generally assign the student in question a grade of "F" for the course and forward the particulars to the Undergraduate Program Director (UPD) for inclusion in the student's folder. If the student is a repeat offender, I ask that the UPD initiate proceedings to dismiss the student from the degree program.

Intellectual dishonesty can end your career, and it is your responsibility to stay on the right side of the line. If you are not sure about something, ask.

Cheating Yourself

Let me also appeal to your better nature, and remind you of what you will miss out on if you engage in dishonest behavior.

This is a demanding course, and computer science is a demanding major. A successful CS student will learn many skills that are in high demand on the job market. In this course, I hope you will learn to modify the Linux kernel---a very valuable skill.

It is my experience that there are some skills that can only be learned through struggling with a problem, such as debugging a complex system or synchronization design. If you "take a shortcut" by cheating, you will nominally complete the assignment, but you are cheating yourself of learning how to fix these problems in the future.

By analogy, this class is like signing up with a personal trainer. If you tell your trainer you did all your exercises while she had her back turned, are you actually going to be stronger?

When you graduate, I hope you will get a good job. Your employer and colleagues will expect you to be a master programmer. If you are not a master programmer, and you won't be if you violate the academic integrity policy, you will not have a long or rewarding career.

In summary, these academic honesty guidelines are in your long-term interest.

Undergraduate Council Statement on Academic Integrity

The following is an official statement required by the Undergraduate Council to be included in any undergraduate syllabus:

Each student must pursue his or her academic goals honestly and be personally accountable for all submitted work. Representing another person's work as your own is always wrong. Any suspected instance of academic dishonesty will be reported to the Academic Judiciary. For more comprehensive information on academic integrity, including categories of academic dishonesty, please refer to the academic judiciary website at http://www.stonybrook.edu/uaa/academicjudiciary/.


Acknowledgements

Most of the materials for this class are based on Prof. Don Porter's offering of the course and some, through Don's work, come from Professors Wong, Stark, Witchel and others. xv6 was developed by Operating Systems course staff at MIT and several other universities. I am very grateful to all these individuals.