CSE 306: Operating Systems

Syllabus and Policies

  1. Prerequisites
  2. Who Can Take This Class
  3. Taking This Class as 587
  4. Examinations
  5. Textbooks
  6. Handouts and Other References
  7. Homework
    1. Lateness
  8. Collaboration vs. Cheating
    1. Cheating Yourself
  9. Grading
  10. Special Assistance
  11. Academic Integrity
  12. Critical Incident Management
  13. Acknowledgements


  1. The officially published prerequisite for this class are These courses are necessary background. In addition, it it is highly recommended that you will have taken CSE 220 during or after the Spring 2011 semester: that's when the syllabus for that course was updated to include substantially more C programming experience, which you will need in this course. If you've taken equivalent courses elsewhere, and they include actual programming experience in C/Unix, please speak to me first to get an approval to take this class. If you've never taken an introductory C/C++ course before, you may not take this class; in some cases, having industry experience in the same field is enough.
  2. You should already know the C programming language and be proficient with it. You should know, for example, how to debug pointer problems and other memory "trashing" bugs that often come up in C programs. This course will not teach you C or basic debugging techniques (though we will discuss how to debug a kernel).
    If you do not know C and would like to take the course, I would recommend reading "The C Programming Language" by Kernighan and Ritchie and working the exercises in the book BEFORE THE FIRST DAY OF CLASS. A dedicated student that is proficient in another language (e.g., Java) can probably accomplish this in a week or two.
  3. You should already have basic exposure to Unix commands. You should know what ssh, cc, gcc, make, ar, as, nm, ln, ld, cpp, vi/emacs, gdb, and other such commands do. We will not teach you how to use Unix (we'd like to spend the time teaching you about operating systems instead).

If you do not fulfill the above requirements, you should very strongly consider postponing CSE 306 until you are more prepared.

Who Can Take This Class

CS undergraduate-level courses are generally intended only for CS undergraduate students in a CSE/ISE degree program such as the BS programs!

If you do not fulfill the class prerequisites, you may not take this class without instructor permission.

Unfortunately, the university registration system does not always validate prerequisites or enforce registrations based on degree programs or department affiliations. Furthermore, we have limited resources available for this class: seating, teaching staff, and laboratory facilities. Therefore, at my discretion, I will collect information about each student who wants to take this class and correlate it with university records. Then I will decide who can take the class. Note that this is independent of whether you are already registered for the class or not. Priority will be given to CSE undergraduate students.

In either case, I will endeavor to allow everyone who has the proper background to take this class, including non-CS majors.

Finally, the lab resources of this class are limited and thus reserved only for registered students. No auditors are allowed in this class.

Taking This Class as 587

In accordance with the policies detailed in the CS Department Graduate Handbook, under certain conditions students admitted to the M.S. program may be permitted to register for this course under the CSE 587 designation. The following special conditions apply to such students:

For the purpose of assigning final course grades, students in CSE 587 will be regarded as a completely separate group from those registered for CSE 306. Thus the distribution of letter grades assigned to students in CSE 587 will have no impact on the distribution of letter grades assigned to students in CSE 306.

I will likely assign letter grades to 587 students according to where they would fall in the grade distribution for 306, but reserve the right to grade them on a separate curve altogether at my discretion.


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

There will be an in-class midterm on Thursday, March 28, 2013. 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.

Special offer: you can write your own exam questions! Submit a question with your solution to course staff in advance of the exam, and if we like it, it will appear on the exam.


Required Textbook: We will be using this book for required course readings, as listed on the course schedule. The readings will not necessarily be in order, and I will supplement the book with additional required and optional resources as needed.

The book is available from the university book stores as well as Amazon and your neighborhood book store.

A number of helpful references for the labs are available on the References page.

Optional Textbooks: The following books are useful references for this course and OS kernel programming in general. These books are available from the amazon and the campus bookstore, and several are available for free on the Stony Brook campus through Safari books online (links below). There is a concurrent user limit for the Safari service; if you have problems with this, let me know and I will ask for it to be increased.

Other recommended operating system textbooks and references:

If you need help with C or Unix, I recommend these texts:

If you are interested in more detail on Linux kernel programming, I recommend these references:

Handouts and Other References

Besides the course text, during the semester we may study some research papers from industry and academia. We will also read parts of the source code of the Linux operating system. These references will be made available via the course home page, at the following URL:



The homework in this course will consist of two types of activities:

  1. Reading from the textbook, assigned papers, and Linux source code. You obviously won't be graded on this part of the homework, but the exams will contain questions to determine whether you have done the reading and integrated the reading material into your own understanding of operating systems. Note also that you are resposible for reading all of the posts on the class mailing list. The list will be an invaluable informational resource for you throughout the class (that's why you must subscribe to it).

  2. Labs in which you will use operating system features, make modifications to a real operating system (Linux) to add new functionality, to change the behavior of the existing system in some way, or to instrument the system to make performance measurements. The course will also include a substantial final project, which will be a larger programming assignment.

Reading will take place on an ongoing basis throughout the semester. There will be four programming assignments, with each assignment due three to four weeks after it is issued. I feel that actual programming experience is extremely important in the systems area, and so I have assigned a fairly high weight to the programming portion of the grade (see Grading below) to help motivate you. If you work in pairs, you should both understand the code, as the exam will also include questions about the labs.

You must work on the first programming assignment alone. You may work with a partner on the 2nd and 3rd assignment, and in a team of up to four students on the final project. You may complete all assignments alone or in smaller groups. Larger partnerships will not be permitted.


Each group has 72 late hours to be used at their discretion throughout the semester. After your late hours are exhausted, each additional day late will incur a full letter grade penalty. In your lab handin code, you must include a file called slack.txt that lists how many late hours you have used.

Conflicts with other courses, research deadlines, holidays, etc. are unavoidable. Thus, you are expected to budget these to account for your other obligations, as well as plan ahead and start early.

The lowest grade you will receive for lateness is a D. If you turn nothing in by the end of the semester for a given lab, you will get an F for that lab

I would recommend turning in what you have by the deadline for a lab, and then submit an updated version late if it will improve your grade after the deducted late penalties. Course staff will generally not grade labs until several days to a week after they are turned in.

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.

Collaboration vs. Cheating

All enrolled students must complete and return a copy of this form, which explains the course policies. Course staff will not grade any assignments for a student until this form is received.

In labs 2 and 3 you may work with a partner; for lab 4, you may work with up to four students. 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:

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.

I am very serious about not tolerating academic dishonesty. In a graduate class, 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.

For more information, see the Academic Judiciary Web site. 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/.

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.


The course will be graded with +/- grades (e.g., A, A-, B+, etc.).

The final grade will be determined as follows: The raw scores obtained by all students on each assignment and exam will be standardized for that particular assignment or exam either (at my discretion) by converting them to percentile scores, or else by applying a linear transformation to map the scores to a standard [0, 100] scale. A weighted sum of the resulting standardized scores will then be formed (with weights as shown below) to obtain a composite score for each student.

Finally, the composite scores will be ranked, and I will apply a subjective method of my choice to determine the cutoffs for each grade category. Absolute performance standards, the distribution of composite scores, information derived from late homeworks, and class participation are factors likely to contribute to this decision.

Generally speaking, to get at least a B+ in this class, your overall numeric grade in this class must be above 75% of the total possible number of points (not counting extra credit). Note that this does not mean that everyone who gets less than 75% will automatically get a grade less than B+.

To pass this course, you have to get at least 50% of the total numeric cumulative grade, not counting extra credit. Note that if you get less than 50%, it does not mean an automatic failing grade, but the grade will not be a good one either.

Attendance and participation in classes, in particular, will be factors that can offset borderline grades. This includes conversations with the instructor and TA over email, using the class mailing list, and so on. I also often take into account evidence of improvement over the course of a semester. However, I will not entertain end-of-term pleas to get a certain grade.

So that you can get an idea of how you are doing as the term progresses, I will report rough percentile information when I hand back each assignment. Final percentile scores will not be computed until after all grade changes and corrections have been taken into account at the end of the term.

The exams are closed book and include a mix of multiple-choice, short answer, and programming questions.

Grading of Programming Assignments: The programming assignments include a grading script that the course staff will use to grade your work. Note that the labs also include questions which affect your grade, but functionality and a correct implementation is the primary factor in grading.

Re-grading: after each grade is given out, you will have a chance to discuss it with the grader and the instructor. You must first discuss your grade with the grader, within the first 48 hours after the grade has been handed back. It's highly recommended that you take some time to review your entire grade before discussing it with the grader. After discussing your grade with the grader, if you wish, you may discuss it with the instructor during office hours or by appointment. If, after discussion with the grader or instructor, you ask for an assignment to be regraded, the entire assignment will be regraded. Your grade can be improved or harmed by regrading.

Extra credit: Some labs may include optional challenge problems, which may be completed for extra credit. Please indicate if you do these in your lab's challenge.txt file. The instructor may also assign bonus work in class at my discretion. Any extra credit points accrued by any student will be used as follows. The final course grade will be assigned as a letter grade which excludes all extra credit points. Then I will apply a subjective method to determine how much value to assign to extra credit points. Extra credit points can only be used to raise your final course letter grade. In other words, you are not obligated to do any of the extra credit work, and you can still get an A in this course.
A note of caution: in the past, some students have spent too much time working challenge problems and gotten behind on core assignments; note that the relative value of extra credit is small compared to the main course assignments.

Working alone on the Lab 2--4: Some of you may choose to work alone on assignments in which may I permit teams; others may work in teams. To be fair to the people who work alone, I often will expect more substantial work accomplished when working in pairs. In addition, when assigning final course grades, I will often apply a subjective method to account for people who worked alone.

Special Assistance

The Provost has required that all faculty include the following statement in their syllabus handouts:

If you have a physical, psychological, medical or learning disability that may impact on your ability to carry out assigned course work, I would urge that you contact the staff in the Disabled Student Services office (DSS), Room 133 Humanities, 632-6748/TDD. DSS will review your concerns and determine, with you, what accommodations are necessary and appropriate. All information and documentation of disability is confidential.

Academic Integrity

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. Faculty are required to report any suspected instances of academic dishonesty to the Academic Judiciary. Faculty in the Health Sciences Center (School of Health Technology & Management, Nursing, Social Welfare, Dental Medicine) and School of Medicine are required to follow their school-specific procedures. 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/

Critical Incident Management:

Stony Brook University expects students to respect the rights, privileges, and property of other people. Faculty are required to report to the Office of Judicial Affairs any disruptive behavior that interrupts their ability to teach, compromises the safety of the learning environment, or inhibits students' ability to learn. Faculty in the HSC Schools and the School of Medicine are required to follow their school-specific procedures.


Portions of this course design, organization, policies, syllabus, web design, etc. came from Gene Stark and Erez Zadok.

Last updated: Fri Feb 15 14:40:58 -0500 2013 [validate xhtml]