COMP 630: Operating System Implementation

Syllabus and Policies

  1. Bulletin Description
  2. General Course Info
  3. Instructor Info
  4. Teaching Assistant(s)
  5. Textbooks and Resources
  6. Course Description
  7. Target Audience
  8. Prerequisites
  9. Goals and Key Learning Objectives
  10. Course Requirements
    1. Lecture Recordings
  11. Grading
    1. Labs
    2. Homework
  12. Course Policies
    1. Lateness
    2. Collaboration vs. Cheating
    3. Cheating Yourself
  13. Disclaimer
  14. Acknowledgements

Bulletin Description

Topics in Computer Science is a graduate seminar. The course has variable content and may be taken multiple times for credit.

General Course Info

Term: Spring 2024
Department: COMP
Course Number: 630
Section Number:138
Time: MW, 3:35-4:50
Location: FB 007

Instructor Info

Name: Dr. Donald Porter
Office: Fred Brooks 344
Email: porter at cs dot unc dot edu
Phone: 919-590-6044
Office Hours: W 2-3:30 PM, or by appointment.

Teaching Assistants

NameOfficeEmailOffice Hours

Textbooks and Resources

There is no required textbook for this course. Readings will be assigned as needed from materials that are available online or from the library.

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

Most of the course materials will be on the course website. We will also use CampusWire for class discussions, and Canvas only for posting assignment grades and videos in Panopto.

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

Other recommended operating system textbooks and references (in no way are these required purchases for the course):

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

Course Description

The primary objective of this course is to gain a detailed understanding of how computer systems work. For instance, when one types a command at the console, what is the chain of hardware and software events that lead to the command returning the correct value? This deep understanding is of practical and philosophical importance. It is practically immportant to understand how computer systems work when you are trying to make them do something new, either for research or industry. More philosophically, a computer scientist with an advanced degree should not view any part of the computer as "magic," but should either understand how it works or have the tools to figure it out.

This course will focus on implementing key OS kernel features in the JOS kernel. JOS provides skeleton code for much of the less interesting components of the OS, allowing you to focus on key implementation details. The JOS lab was developed at MIT, and has been used at several other universities, including Stanford, Texas, and UCLA.

Lectures and readings in the course will serve to draw out general principles, add needed background for the labs, and map details from the JOS implementation to real-world OSes, like Linux and Windows. In my own experience, most of the mapping is fairly intuitive: once you understand the simple code in JOS, the same pattern is clear in the much more complicated Linux source code.

This course will not attempt to provide a comprehensive introduction to operating systems. Some previous exposure to the basics of multi-programmed operating systems will be assumed.

Target Audience

The course is geared towards graduate students and advanced undergraduate students in computer science, who have already taken an undergraduate operating systems course (COMP 530 or equivalent). This course will focus on developing a deeper understanding of how operating systems work in practice, and honing the implementation skills required to build real computer systems.


The prerequisites for this class is COMP 530 (Operating Systems), or an equivalent course at your undergraduate institution. For undergraduates, you should earn a B+ or higher in 530 to be prepared for this course. This course is necessary background. In some cases, significant industry experience can be sufficient background. If you are not sure whether you are prepared, please arrange an appointment with the instructor to discuss your preparation further.

Self-Assessment: For students with an atypical background, you can do this short quiz to help assess your preparation. This does not necessarily cover every background topic, but if you cannot comfortably answer half of the questions without the aid of the internet, you should take COMP 530 first. This quiz will not be graded or collected, but the instructor will discuss it with you if you have questions.

C Programming: You should already know the basics of programming and debugging in C programming language. This course will be taught in C, and you will complete substantial, kernel-level programming assignments in C. We expect that a typical student will become much more proficient in C over the course of the semester. However, because this is not a C course, the time spent in class on C will be minimal.
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.

You should already have basic exposure to Unix commands and the command line. You should know what commands such as ssh, gcc, make, man, ls, mkdir, vi/emacs, and gdb do, or be able to figure this out on your own (via google and friends). In general, we will not teach you how to use Unix (we'd like to spend the time teaching you about operating systems instead), although we may discuss particularly tricky commands.

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

Goals and Key Learning Objectives

Students will learn how to write OS kernel code in C and a small amount of x86 assembly. Students will implement major components of the OS kernel, including page tables, scheduling, and program loading. The course will include an open-ended final project.

Course Requirements

The course is taught in an interactive lecture style. Although there are slides and planned topics to discuss, students are expected to answer questions during the lecture and ask questions. Attendance is expected, but will not be recorded.

Students are also expected to complete roughly 6 programming assignments. The programs will be written in the C and x86 assembly programming languages on a departmental Linux server and will each emphasize some aspect of operating system design and implementation.

Lecture Recording

Lectures will be recorded and be made available to the students in the class. These recordings are intended to help students review the material after attending lectures, and are not a substitute for attending lectures in person. Lecture attendance is still expected, to facilitate questions, announcements, and discussion. If lecture recording substantially harms attendance, it will be discontinued.

This is a best-effort service and should not replace lecture attendance. Student questions, chalkboard drawings, and other materials may not record properly. Moreover, my experience has been that a few lectures are lost each semester for unforeseen technical difficulties (e.g., the recording space fills up mid-lecture, a file gets corrupted).


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.

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, contributing on Piazza, 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 exam. 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.

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.

Groups: You may form groups of up to three members for the assignments. All group members must be enrolled in the course, and listed in comments in the handed-in assignment. All group members are responsible for all code that is handed in. A word to the wise: Think carefully about who you work with - a poor group member can harm your grade beyond repair. Further, it is my experience that when students do not substantially participate in programming homeworks, but rather let their partner(s) do the work for them, they tend to perform poorly on exams.

The instructor reserves the right to quiz or otherwise question any student about their understanding of work handed in; failure to explain the code satisfactorily is grounds for losing all points on the assignment. If an assignment is found to constitute academic dishonesty, all group members are considered responsible and will all be reported to Honor Court.

Changing Groups: The projects are cumulative, and you may not change groups without instructor consent, and this will require explicit guidance on which base code to use for subsequent assignments


This semester, there will be one take-home, final "exam", which will actually be an individual Linux kernel coding assignment. This will replace the final exam, and will be due during the final exam period.


The out-of-class work in this course will consist of three types of activities:

  1. Reading from the textbook, assigned papers, and Linux source code. The main purpose of reading is to provide you with other means to learn the material. Reading in advance of class and giving the basics time to digest also helps one understand more subtle concepts that are explained in class. You obviously won't be graded on the readings per se, but reading can improve your exam scores.
    Note also that you are resposible for reading all of the posts on the class mailing list (on Piazza this semester). 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 gain hands-on experience using operating system features. Each homework assignment will be graded, and you will be expected to do this alone or with a team.

Reading will take place on an ongoing basis throughout the semester. There will be roughly six programming assignments, with each assignment due a few weeks after it is issued. If you work with a partner, all members you should understand the code, as the exam will also include questions about the labs.

You may work alone or with a partner on all labs. You may change partners between assignments. Larger partnerships will not be permitted.

Course Policies

The course final is given in compliance with UNC final exam regulations and according to the UNC Final Exam calendar.


Each team has 72 late hours to be used at their discretion on programming assignments 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 last day of classes for a given lab, you will get an F for that lab. If you turn in all programming assignments on the last day, late assignments may receive up to 60% of the credit.

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 four 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.
  4. If late hours are insufficient to accommodate a religious observance, you may request an accommodation from the University Relgious Accommodations Advisory Committee using this form.

No extensions will be given for any other reason.

Honor Code

All enrolled students must complete a homework that explores academic integrity (available in gradescope). Course staff will not grade any assignments for a student until this form is received.

Students are encouraged to study together. The policies below apply to programming assignments (labs).

In the labs you may work as a team. If you work alone, you submit your own work. If you work in a team, what you submit may only have been written by team members, and all team members should understand and have contributed to the code handed in. 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 teammates.

The code you and your partner submit must be your own work, and only your own work. Failure to document/attribute which students in the class contributed to the assignment is grounds for all students losing points on the lab. Using outside sources (the internet, previous courses, help from anyone not enrolled in the course or course staff), constitutes academic dishonesty and will be referred to the student attorney general. Any evidence that source code has been copied, shared, or transmitted in any way between non-teammates (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.), unless otherwise noted. 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. Unacceptable collaboration, copying or unapproved use of any code, or failure to attribute sources used to formulate a homework solution will be considered a violation of the UNC Honor Code and will be reported to the Student Attorney General.

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 do low-level system programming---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, you will not be if you violate the academic integrity policy, and you will not have a long or rewarding career.

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


The professor reserves to right to make changes to the syllabus, including project due dates and test dates. These changes will be announced as early as possible.


Portions of this course design, organization, policies, syllabus, web design, etc. came from Gene Stark, Erez Zadok, Michael Bender, Michael Ferdman, and Kevin Jeffay.

Last updated: 2024-01-14 19:30:12 -0500 [validate xhtml]