E81 CSE 522S: Advanced Operating Systems

Spring 2019

Acknowledgement: portions of this course and web site are adapted (with permission) directly from the materials
that were originally developed and taught at Washington University by David Ferry in the spring semester of 2016.

Instructor Chris Gill (office hours by appointment)
Course Web Site
Course Meetings Mondays and Wednesdays 8:30 - 10:00 AM.
Most days will start with a brief lecture and discussion in Urbauer 218, followed by assisted group work on studios and labs.
Exams will be held in Jolley 309 and will occupy the entire meeting time on their designated dates.
First Exam
8:30-10am, Mon, Feb 25th, Jolley 309
Second Exam
8:30-10am Wed, Apr 10th, Jolley 309
Prerequisites CSE 422S (Operating Systems) and C/C++ programming experience are firm prerequisites for this course.

  1. Course Description
  2. Prerequisites
  3. Discussions/Studios
  4. Labs
  5. Course Project
  6. Class FAQ
  7. Textbooks and Other Resources
  8. Grading
  9. Accessibility
  10. Academic Integrity

Course Description

This course intends to give hands-on experience working with the Linux operating system kernel, to address issues well beyond the scope of a basic operating systems course. Profiling, quantifying, modifying, and optimizing program and operating system behaviors as different policies and mechanisms interact are key themes of this course, as is understanding how those policies and mechanisms govern those behaviors.

The objectives of this course are for each student to:

This is a hands-on graduate-level course dealing with complex systems software, which is being substantially revised again this semester (largely to refine the ordering of topics and give more attention to issues that arose in its previous edition). Hiccups are to be expected, and finding new and exciting ways to break course exercises is encouraged, as the instructor continues to fine-tune the content and scope of each class meeting.


Discussions and Studios

This course is conducted in a studio format, both to emphasize the practical and hands-on nature of "kernel hacking" and to engage students in applied active learning exercises. The focus of lecture components is to facilitate in-class discussion of kernel design and features, while the focus of studio exercises is (1) to offer direct experience working with (and within) the kernel and (2) to familiarize students with key tools and techniques for kernel development, profiling, analysis, and optimization. The studios, labs, and course project will be completed as small group exercises, and are submitted for credit. All studios assigned prior to the first exam are due the night before it, and all studios assigned after the first exam are due the night before the second exam (please see the day-by-day syllabus for the precise deadlines).

Most class periods are accompanied by suggested readings. The Linux kernel is a particularly compelling subject of study, in that many of the discussions (and disagreements) among the original developers have been saved verbatim in repositories such as the the Linux Kernel Mailing List (LKML) or documented by firsthand witnesses at sites such as The course textbooks can be used as technical references for kernel mechanisms, and supplemental readings in them can be used to understand the particular design choices made in the course of kernel development.

The course schedule is as follows. Note that this schedule may change over the course of the semester. If changes occur, students will be notified in class and in Canvas and given enough advance notice so that readings and other preparation may be accommodated.

# Date Topic Readings Studios/Labs
1 Mon, Jan 14th Course Introduction

Academic Integrity
LKD chapters 1 & 2
LSP chapter 1
the Linux source tree
Cross-compiling the Linux kernel

Setting up the Raspberry Pi 3
2 Wed, Jan 16th Inter-process communication: signals LSP chapter 10
(optionally, also LPI chapters 20-22)
man 7 signal
man sigaction
man 2 write
Linux Signals
Mon, Jan 21st: Martin Luther King Jr. Day - no classes
3 Wed, Jan 23rd Inter-process communication: pipes LKD Ch. 3 (parent and child processes)
man 2 pipe
man 2 read
(and man 2 write)
man 3 mkfifo
(optionally, also LPI chapters 43-44)
The LPG Pipes and FIFOs pages
Linux Pipes and FIFOs
4 Mon, Jan 28th Inter-process communication: sockets (optionally, also LPI chapters 56-59)
man 2 bind
man 7 unix
man 7 ip
Linux Sockets
5 Wed, Jan 30th Inter-process communication: shared memory LSP pp. 104-118
LKD Ch. 15
(optionally, also LPI chapters 48-49, 54)
IPC performance comparison
6 Mon, Feb 4th I/O multiplexing mechanisms LSP pp. 51-62, 97-103
(optionally, also LPI chapter 63)
I/O event handling
7 Wed, Feb 6th Overview of the lab 1 assignment   In-class lab (or studio catch-up) time
Lab 1 Assigned (due Tue, Feb 19th at 11:59PM)
8 Mon, Feb 11th More I/O performance considerations LSP pp. 91-97, 118-135
LKD Chapter 14
In-class lab (or studio catch-up) time
9 Wed, Feb 13th Enforcing real-time behavior I LSP pp. 190-209
LKD Chapter 4
Fixed-priority real-time behavior
10 Mon, Feb 18th Enforcing real-time behavior II LSP pp. 217-218, 224-225
Professor Lu's CSE 520S slides on End-to-end Scheduling
In-class lab (or studio catch-up) time
Lab 1 due Tue, Feb 19th at 11:59PM
11 Wed, Feb 20th First Exam Review in Urbauer 218    

All studios assigned so far are due Sun, Feb 24th at 11:59pm

12 Mon, Feb 25th
First Exam 8:30-10am in Jolley 309
13 Wed, Feb 27thOverview of the lab 2 assignment   Lab 2 Assigned (due Wed, Mar 27th at 11:59PM: note 24 hour extension!)
14 Mon, Mar 4th No lecture: graded midterm exams returned and discussed   In-class lab time
15 Wed, Mar 6th Timing forensics LKD Chapter 11
LPI Chapters 10, 23 (optional)
Observing timing events
Mon Mar 11th and Wed Mar 13th: Spring Break - no classes
16 Mon, Mar 18th
Class Canceled
17 Wed, Mar 20th Process forensics LKD Chapter 3
LSP Chapters 5 and 6
LPI Chapters 24-27 (optional)
Process forensics
18 Mon, Mar 25th Memory forensics LSP Chapter 9 (especially pp. 315-316)
man 3 mallinfo
man 3 mallopt
man 2 eventfd
LPI Chapter 7 (optional)
Observing memory events
19 Wed, Mar 27th Course projects
File system forensics
Course project requirements
LSP Chapter 8 (especially pp. 283-292)
man strings
LPI Chapter 19 (optional)
Observing file system events
Lab 2 due Wed, Mar 27th at 11:59PM (note 24 hour extension!)
20 Mon, Apr 1st Anomaly detection and defense I   Self-inflicted anomalies
21 Wed, Apr 3rd Anomaly detection and defense II   Externally-induced anomalies
Project plans due Fri, Apr 5th at 11:59PM
22 Mon, Apr 8th Second Exam Review in Urbauer 218   All studios assigned after the First Exam are due Tue, Apr 9th at 11:59pm
23 Wed, Apr 10th
Second Exam 8:30-10am in Jolley 309
24 Mon, Apr 15th
Guest Lab Facilitators:
Son Dinh and James Orr
    In-class project time
25 Wed, Apr 17th
Guest Lab Facilitators:
Son Dinh and James Orr
    In-class project time
26 Mon, Apr 22nd Project Presentations I in Urbauer 218.
27 Wed, Apr 24th Project Presentations II in Urbauer 218

All project code and reports due Fri, May 3rd at 11:59pm


There will be two lab assignments for this course. The purpose of these labs is to apply course concepts and to evaluate competing design alternatives for kernel mechanisms. As such, each lab will require a written report detailing your findings in addition to a code submission.

Each lab will be completed in a team of two or three students, and teams may be different for each lab. Students from different teams may discuss the lab assignments only during course meeting times. Students on the same team are of course encouraged to discuss and work on lab assignments at any time.

Labs submitted on time (as determined by the email server's receipt time stamp) will be given full credit. Labs submitted up to 24 hours late will be given a ten percent penalty. Labs submitted between 24 and 48 hours late will be given a twenty percent penalty. Labs submitted after 48 hours late will not be given credit, except in the case of extenuating circumstances approved by the instructor.

Course Project

The course project gives a team of two or three students an opportunity to propose and complete their own significant extension of, or modification to, the Linux kernel. This may be an entirely new capability or an alteration to some existing functionality. Each team will evaluate the effectiveness of its modification by developing their own test cases that can successfully demonstrate the new behavior. Students are encouraged to look to their own labs, interests, and/or research projects for inspiration and ideas for projects.

In either case, students will justify their proposal in a written document, in order to ensure that the scope of the project is achieveable. The proposal document will:

  1. Propose a modification of, or extension to, Linux kernel behavior
  2. Clearly explain the purpose of the modification or extension
  3. Identify any kernel files that will require modification or extension
  4. Identify any kernel data structures that will need to be changed or extended
  5. Identify any kernel concepts and control paths that will need to be changed or extended
  6. Propose a set of test cases that demonstrate and test the modification or extension
  7. Identify any kernel modules or user space programs that will be produced in order to implement, or to validate and test, the modification or extension
  8. Include a five-week planned schedule for the project, including detailed design, implementation, initial evaluation, project presentation, and project writeup phases.

The project will be evaluated in part based on a live presentation at the end of the semester, as well as based on submitted code and documentation. This presentation should explain the modification or extension to the other students in the course; describe any alterations or extensions to kernel files, data structures, or concepts; present timing graphs or other data to verify the behavior of the modified system; and may include a short demo (if possible within the allotted time).

Class FAQ

Current and past instructors, TAs, and students of this course have contributed various tips, tricks, and solutions to problems that they have encountered. Please let your instructor know if you have something you'd like to add here!

Class FAQ

   What if your Pi is freezing up?

   Leaving your Pi at home

Textbook and Class Resources

Students should consider the in-class studios and assigned readings to be a guided tour of the Linux kernel. Like any good tour group, we want to see the sights and learn some neat highlights about who built it and what they were trying to accomplish. But, the studios and assigned readings will not make you an expert on the Linux kernel. When it comes to learning the details of a code base as deep and complex as this, there is no substitute for reading source code. Lectures and studios will come with pointers to relevant source code files, and it is expected that students will spend time absorbing the content there as well. Therefore, assigned readings are kept moderately short with the expectation that you will spend some independent time in the source code.

To be clear, you are not expected to understand or memorize every line of the Linux source. Exams will not have questions derived from the Linux source (though basic kernel concepts and pseudo-code are fair game). However, the kernel is a huge set of deeply interdependent source code files. The only way you will ever understand it is by looking through it many times.

There are two required course textbooks: Linux Kernel Development by Robert Love, 2010 (noted as LKD in the assigned readings) and Linux System Programming by Robert Love, 2013 (noted as LSP in the assigned readings). These are both excellent, compact, and inexpensive texts that give the reader a basic understanding of Linux kernel and library design and usage, written in depth by an expert Linux veteran.

Readings in one optional additional course textbook also will be suggested: The Linux Programming Interface by Michael Kerrisk, 2010 (noted as LPI in the suggested additional readings, which will be added to the syllabus as the semester progresses).This an excellent, somewhat more extensive reference manual, also written in depth by an expert Linux veteran.

There are a variety of other useful references as well. None of these will give you the level of competency that comes from looking at code itself, but they are very useful for starting points and clarifying problems. However, the Linux kernel is rapidly updated, so while the general information in these books is correct, details such as source code, names of files, and where files exist is likely to can and does change.

Students will require a Raspberry Pi 3 in order to complete daily studios and lab assignments. The course has been designed with the intention that students bring these devices to class, plug them in, and do some hacking there. Monitors, keyboards, and mice will all be provided for this purpose- you will need to provide the Raspberry Pi 3, a power cord, and an HDMI cable.

If you so desire, you may set up your Raspberry Pi 3 in your home or office and configure it for remote access. However, the instructor cannot support you in this, and we are modifying the kernel so you may be rather lost if you reboot and can't ssh back into your machine. Also, be forewarned that some exercises will require an X11 window, so simple ssh access will not be enough to do everything remotely.


There are four activities for which you will receive credit in this course: studios, labs, exams, and the course project. Studios are daily guided assignments primarily designed to familiarize students with course concepts, development tools, and the kernel source code (i.e. knowledge and comprehension tasks). Two lab assignments will ask students to apply general course concepts and analyze kernel design alternatives. The course project requires that students propose and complete a novel kernel modification. Two in-semester exams will evaluate your technical understanding of course concepts.

Your grade will be determined as follows:

Activity Grade Percentage
First Exam 12%
Second Exam 18%
Studios 20%
Lab 1 10%
Lab 2 15%
Course Project 25%


Students with disabilities or suspected disabilities are strongly encouraged both to bring any additional considerations to the attention of the instructor and to make full use of the University's Disability Resource Center (, potentially including accommodations for exam conditions or durations.

Academic Integrity

Each studio, lab, and project assigned in this course is expected to be completed collaboratively by two or three people (and not more or less than that). Student teams may change from assignment to assignment, but the sharing of code between teams working on the same assignment is strictly prohibited, and you must acknowledge and document in detail all contributions that anyone has made to the work.

Exams must be completed individually without assistance from any other person and without reference to materials or devices, except as specifically allowed by the instructor (documentation of what is allowed will be described in class, provided in the corresponding review slides, and written on the font page of the exam).

Cheating costs everyone something. Someone who cheats misses out on the intended opportunity to improve through the assigned work, and like anyone helping them cheat is at risk of diminshed reputation as well as of specific sanctions. Cheating also degrades the value of the degree earned by those who complete their work with integrity.

We take academic integrity very seriously in this course, and any cases of cheating will be referred immediately to the Engineering School's academic integrity process. The instructor will make final determinations on whether or not to make any such referral. If in any doubt, please ask first.

Acadmic integrity is itself worth studying and thinking about as a key component of your education. Please read, familiarize yourself with, and reflect on the Engineering School's and Washington University's undergraduate and graduate policies on academic integrity.