engineering.wustl.edu

E81 CSE 422S: Operating Systems Organization

Fall 2023

Acknowledgement: portions of this web site and the course materials linked from it have been derived (with permission) directly from materials that were originally developed and taught at Washington University by David Ferry in the spring semester of 2016 and subsequently revised and extended by Chris Gill, Brian Kocoloski, James Orr, and Marion Sudvarg.


Instructor James Orr (Office Hours: during class times and by appointment)
Teaching Assistants Alan Shao office hours 4-5pm Tuesday/Thursday via Zoom (check Piazza for link)
Zichen Wang office hours 4-6pm Friday Urbauer 216
Brendan Yang office hours 3-5 Tuesday, 10-12 Friday via Zoom (check Piazza for link)
Riley Haffner office hours 11:30am-1pm Monday/Wednesday via Zoom (check Piazza for link)
Matt Weinberg office hours 2:30-4pm Tuesday McKelvey 1030, Thursday Cupples I 216
Ethan Woolbert office hours during class
Course Web Site https://classes.engineering.wustl.edu/cse422/
Piazza Page https://piazza.com/wustl/fall2023/cse422s

Course Meetings

The regularly scheduled class meetings (Tuesdays and Thursdays 10:00am - 11:20am in Urbauer 218) will begin with a relatively short lecture and discussions, and the remaining time will be assisted group work on studios and/or labs.

Students will be expected to keep up on the readings and lectures, to use Piazza and other course resources, and (if necessary) to attend sufficient TA office hours each week, in order to be able to understand and apply the technical material in the course, to ask and get answers to questions about the material, to prepare for the exams, and to get help debugging studio and lab assignments. Each student is responsible for determining how much engagement in each of those modes is needed for them to learn and perform effectively in the course.

Students should also please read and follow Washington University's COVID-19 Health and Safety Protocols and other related policies.

Exam 1
Tuesday, October 17th
Exam 2
Thursday, December 7th
Prerequisites CSE 361S (or graduate student standing) and C/C++ programming experience are strictly required
CSE 332S/504N or CSE 428S is encouraged but not required

Contents
  1. Course Description
  2. Prerequisites
  3. Discussions/Studios
  4. Lab Projects
  5. FAQ/Tips
  6. Computers, Textbooks, and Other Resources
  7. Grading
  8. Academic Support
  9. Title IX, Diversity, and Inclusion
  10. Academic Integrity

Course Description

This course intends to give hands-on experience working with the Linux operating system kernel, and covering a breadth of basic operating systems issues. The course will emphasize developing and applying skills and techniques for profiling, quantifying, and evaluating operating system behaviors based on an understanding of the policies and mechanisms that govern those behaviors.

The objectives of this course are for each student to:

This is a hands-on 400-level course dealing with complex system behaviors, using off-the-shelf platforms and software. Hiccups are to be expected, and finding previously unknown flaws in (or improvements to) the course exercises is encouraged, as the instructors and TAs involved with this course pursue ongoing refinement of the content and scope of this course over time.


Prerequisites

The following are firm prerequisites:

The following are recommended but not required:


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 using, profiling, analyzing, and extending kernel features. Studios and the labs may be completed in groups of up to 3 students, and are submitted for credit.

Most class periods are accompanied by additional assigned readings (and possibly additional suggested readings that may be useful). The Linux kernel is notable 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 lwn.net. The course textbooks can be used as technical references for kernel mechanisms, and the suggested supplemental readings can be used to understand particular design choices affecting the Linux kernel.

The course schedule is as follows. In the event that the schedule changes, students will be notified both in class and through a Piazza post, and will be given enough advance notice so that rescheduling readings and other preparation can be accommodated readily.

`
# Date Topic Readings/Resources Studio/Lab
1 Tue, Aug 29th Academic Integrity
Introduction to Linux
LKD chapters 1-2
A Brief Overview of the Linux Source Tree
Building the Linux Kernel
2 Thu, Aug 31st   LPI chapters 1-3 Setting up the Raspberry Pi 4B/4/3B+
(open studio time: no lecture today)
3 Tue, Sep 5th How and When Does the Kernel Run? LKD chapter 5
Userspace / Kernelspace API Split
System Call Source Code Pointers
Creating a Syscall
4 Thu, Sep 7th Structure and Infrastructure of the Linux Kernel LKD chapter 6 and pp. 338-348 (chapter 17 Modules through Exported Symbols)
A simplified IDR API
Writing a kernel module
5 Tue, Sep 12th Processes LKD chapter 3
man 3 fork
man 3 exec
LPI chapters 20.1, 24.1-24.2, 24.4, 25, 26.1.1-26.1.4, and 26.2
Linux Process Source Code Pointers
Linux Kernel Code Error Checking
The ERR_PTR and PTR_ERR macros
How to use IS_ERR and PTR_ERR? What do they mean?
Process Family Tree
6 Thu, Sep 14th Time Sources and Timing LKD chapter 11
LPI chapter 23.1-23.6.6
A Brief Guide to Time in Linux
Description of the Timer Wheel System
High Resolution Timers Subsystem
hrtimer Patch (Formerly ktimers)
ktime accessors
Timing and Benchmarking
7 Tue, Sep 19th Kernel Tracing and Debugging
LKD pp. 363-371 (chapter 18 Debugging through Asserting Bugs and Dumping Information)
Ftrace overview document
KernelShark (and its Git repository)
Ftrace Source Code Pointers
Tracing with Ftrace and Kernelshark
8 Thu, Sep 21st Kernel Synchronization I

Overview of the Lab 1 Assignment
LKD chapter 9 Lab 1 Assigned
(due Thu, Oct 19th at 11:59PM)


In-class lab (or studio catch up) time
9 Tue, Sep 26th Kernel Synchronization II LKD chapter 10
What is RCU, fundamentally?
Kernel Reference on RCU
Kernel Races, Atomicity, and Synchronization
10 Thu, Sep 28th Userspace Synchronization LPI chapters 30 and 31
Read these man pages (opened when you run these commands) on a Linux machine:
man 7 futex
man 2 futex
Build Your Own Locks
11 Tue, Oct 3rd Traditional Process Scheduling LKD chapter 4 (except for pp. 64-65 Real-Time Scheduling Policies)
LPI chapter 35.1 and 35.4
Completely Fair Scheduling
12 Thu, Oct 5th Real-Time Process Scheduling LKD pp. 64-65 (chapter 4 Real-Time Scheduling Policies)
LPI chapter 35.2, 35.3, and 35.5
Deadline Scheduling vs POSIX Real-time Scheduling
Thread prioritization in kernel modules
The on-line man 7 sched page.
Real-Time Scheduling
Tue, Oct 10th : Fall Break - no classes
13 Thu, Oct 12th Exam 1 Review All studios assigned so far are due by Thu, Oct 12th at 11:59PM
14 Tue, Oct 17th Exam 1
15 Thu, Oct 19th Virtual Memory and Paging
Kernel Memory

Overview of the Lab 2 Assignment
LKD chapter 12 Kernel Memory Management

Lab 2 Assigned (due Tue, Nov 14th at 11:59PM)

Lab 1 due by Thu, Oct 19th at 11:59PM
16 Tue, Oct 24th Address Spaces / Shared Memory LKD chapter 15
Read these man pages (opened when you run these commands) on a Linux machine:
man 2 mmap
man 3 shm_open
Shared Memory Management
17 Thu, Oct 26th Program Execution, Linking, Layout LPI chapters 24.1-24.2, 27.1-27.2
LKD pp. 29-32 and 38-40 (chapter 3 from Process Context through Forking, and then The Dilemma of the Parentless Task)
The inside story on shared libraries and dynamic loading
Read these man pages (opened when you run these commands) on a Linux machine:
man 1 ldd
man 1 nm
man 1 readelf
man 1 pmap
Program Execution and Debugging
18 Tue, Oct 31st Virtual Filesystem LKD chapter 13 VFS Layer
19 Thu, Nov 2nd Buffer and File I/O LPI Chapters 4, 5, and 13
Read these man pages (opened when you run these commands) on a Linux machine:
man 2 read
man 2 write
man 2 readv
man 2 writev
man 3 stdio
Buffer and File I/O
20 Tue, Nov 7th Inter-Process Communication: Pipes and FIFOs LPI chapters 44.1-44.3, 44.6-44.11
The LPG pages on Pipes and FIFOs
Read these man pages (opened when you run these commands) on a Linux machine:
man 2 pipe
man 3 mkfifo
man 3 getline
Linux Pipes and FIFOs
21 Thu, Nov 9th Inter-Process Communication: Sockets LPI chapters 12.2, 56.1-56.6, 57.1-57.2, 57.4, 58.5, 58.6.1, 59.1-59.6, 59.10, 59.11
Read these man pages (opened when you run these commands) on a Linux machine:
man 2 bind
man 7 unix
man 7 ip
man 3 htons
man 3 getaddrinfo
man 2 gethostname
man 3 getnameinfo
Sockets
22 Tue, Nov 14th I/O Multiplexing Mechanisms and Performance Considerations

Overview of the Lab 3 Assignment
LPI chapter 63
LKD chapter 14
I/O Event Handling

Lab 3 Assigned (due Tue, Dec 12 at 11:59PM)

Lab 2 due by Tue, Nov 14th at 11:59PM
23 Thu, Nov 16th Signals LPI chapters 20, 21.1, 21.4-21.6, 22.1-22.8, 24.5, 26.3
Read these man pages (opened when you run these commands) on a Linux machine:
man 7 signal
man 7 signal-safety
man 2 sigaction
man 2 write
man 2 getrlimit
Linux Signals
24 Tue, Nov 21st Interrupts and Interrupt Handlers LKD chapter 7
Linux source: current irq flags
Why IRQF_DISABLED is no longer used
In-class lab (or studio catch up) time
Thu, Nov 23rd : Fall Break - no classes
25 Tue, Nov 28th Bottom Half Processing LKD chapter 8
Linux source: current softirqs
Threaded interrupt handlers
Software Interrupts and Real-time
In-class lab (or studio catch up) time
26 Thu, Nov 30th In-class lab (or studio catch up) time
27 Tue, Dec 5th Exam 2 Review   In-class lab (or studio catch up) time
All studios assigned since Exam 1 are due by Tue, Dec 5th at 11:59PM
28 Thu, Dec 7th Exam 2

Lab 3 due by Tue, Dec 12 at 11:59PM

Lab Projects

There will be three lab assignments for this course. The purpose of these labs is to apply course concepts and to evaluate kernel mechanisms and behaviors. As such, each lab will require a written report detailing your findings in addition to the code you wrote.

Each lab will be completed in a team of up to three students, and teams may be different for each lab or may remain the same. Students from different teams may discuss the lab assignments only during regularly scheduled sessions (class meeting times and regular weekly TA office hours) that the instructors or TAs are attending, when anyone is able to join in those discussions. 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 timestamps in Canvas) will be graded for full credit. Labs submitted up to 24 hours late may be given a ten percent penalty. Labs submitted between 24 and 48 hours late may be given a twenty percent penalty. Labs submitted after 48 hours late may not be given credit, except in the case of extenuating circumstances approved by the instructor. If you anticipate that your team may need an extension on a lab assignment, please make sure to ask prior to the deadline.


FAQ/Tips

Current and past instructors, TAs, and students of the CSE 422/522 courses 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?

   Accessing your Raspberry Pi Remotely


Computers, Textbooks, and Other Resources

To be able to complete the studios and lab assignments this semester, you will need to acquire (e.g., purchase) a Raspberry Pi 3 B+, Raspberry Pi 4, or a Raspberry Pi 4B, which are the platforms on which we have tested out our solutions to those assignments, and on which we will be grading them.

Kits may be purchased, if available, from any of the following links. For purchases directly from the CanaKit website, any kit with an "Add to Cart" button that doesn't show a pre-order date means it's in stock.

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, Micro SD card, and power cord (all of which should be included in the kits linked above).

If you use a Raspberry Pi 4, you may need to additionally purchase a Micro-HDMI to HDMI adapter (if not already included in the kit you purchased). You do not need this if you are using a Raspberry Pi 3 this semester. We recommend the following adapter:

https://www.amazon.com/gp/product/B00JDRHQ58/

If you so desire, you may set up your Raspberry Pi in your home or office and configure it for remote access. However, the instructor and TAs 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 two required textbooks for this course:

Linux Kernel Development by Robert Love, 2010 (noted as LKD in the assigned readings). This is an excellent, compact, and inexpensive text that gives the reader a basic but also reasonably detailed understanding of kernel design, written in depth by a Linux kernel expert.

The Linux Programming Interface by Michael Kerrisk, 2010 (noted as LPI in the assigned readings). This an excellent, somewhat more extensive reference manual, also written in depth by a Linux kernel expert.

Please note that the Linux kernel source code is frequently (and sometimes rapidly) updated, so that while the general information in these textbooks is correct, many details of the source code itself, the names of source code files, and where those files exist, are somewhat likely to change (and have done so since the required text books above and the additional references below were written).

The in-class studios and assigned readings will offer a reasonable coverage of Linux. However, the studios and assigned readings will not yet make you an expert on the Linux kernel. When it comes to learning the details of a code base as deep and complex as Linux, there is no substitute for reading source code. Some of the lectures and studios will give pointers to relevant source code files, and for overall understanding it is expected that students will spend some time absorbing the content there as well.

To be clear, you are not expected to understand or memorize every line of the Linux source. The exams will not have questions derived directly 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. A useful way to understand it more and more thoroughly is by looking through different parts of it many times.

There are a number of other references that you may find useful for this course and more broadly for your study and use of the Linux kernel.

Students will need to acquire a Raspberry Pi 4B, 4, or 3 B+ in order to complete daily studios and lab assignments. If you run into any problems using your Raspberry Pi in this course this semester please let us know right away so we can help.


Grading

There are three activities for which you will receive credit in this course: studios, exams, and labs. Studios are daily guided assignments primarily designed to familiarize you with course concepts, development tools, and the kernel source code (i.e. knowledge and comprehension tasks). Exams will evaluate your technical understanding of course concepts, including nuances of the material covered in the lectures and in the assigned readings. The lab assignments will ask you to apply course concepts and analyze and implement design alternatives.

We will make every effort to grade each of your studios, and to post a grade in Canvas and provide comments to you regarding it, within one week (7 days) of when it is submitted. We will strive to post exam grades and return graded exams within 10 days, and for lab assignments will work to do so within 14 days.

Especially for the early studios, even though they are not due until just before the first exam, please do work to submit them as early as you can so that you'll have grades and feedback on at least a few of them prior to the end of the semester's drop/add period.

Your semester grade will be determined as follows, with an overall weighted average of 90% corresponding to at least an A-, of 80% corresponding to at least a B-, and of 70% to at least a C- (and to a passing grade if the course is being taken P/F rather than for a letter grade):

Activity Grade Percentage
Studios 20%
Exam 1 20%
Exam 2 20%
Lab 1 10%
Lab 2 15%
Lab 3 15%

Academic Support, Health and Wellness, and Disabilities

We encourage everyone to take a look at, and potentially make use of, the many academic support resources available at Washington University in St. Louis, including: The Learning Center, and The Writing Center, and Student Technology Services.

Washington University recognizes that students serving in the U.S. Armed Forces and their family members may encounter situations where military service forces them to withdraw from a course of study, sometimes with little notice. Students may contact the Office of Military and Veteran Services at (314) 935-2609 or veterans@wustl.edu and their academic dean for guidance and assistance.

The Habif Health and Wellness Center, WashU Cares, Mental Health Services, and RSVP are important university resources for issues pertaining to physical and mental health.

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 Washington University's Disability Resources, potentially including accommodations for studios, labs, and/or exams.


Title IX, Diversity, and Inclusion

Washington University is firmly committed to addressing and preventing sexual misconduct on our campuses: please see the Washington University statement on new Title IX rules. If a student discusses or discloses an instance of sexual assault, sex discrimination, sexual harassment, dating violence, domestic violence or stalking, or if a faculty member otherwise observes or becomes aware of such an allegation, the faculty member will keep the information as private as possible, but as a faculty member of Washington University, they are required to report it immediately to their Department Chair or Dean or directly to Ms. Jessica Kennedy, the University's Title IX Director, at (314) 935-3118 or jwkennedy@wustl.edu. Additionally, incidents or complaints can be reported to the Office of Student Conduct and Community Standards or by contacting WUPD at (314) 935-5555 or contacting your local law enforcement agency. To explore options for medical care, protections, or reporting, free and confidential support resources and professional counseling services are available through the Relationship and Sexual Violence Prevention (RSVP) Center in Seigle Hall, Suite 435, which can be reached at rsvpcenter@wustl.edu or at (314) 935-3445. For after-hours emergency response services, call 314-935-6666 or 314-935-5555 and ask to speak with an RSVP Counselor on call.

Washington University's Center for Diversity and Inclusion supports and advocates for undergraduate, graduate, and professional school students from underrepresented and/or marginalized populations, collaborates with campus and community partners, and promotes dialogue and social change to cultivate and foster a supportive campus climate for students of all backgrounds, cultures, and identities. The University has a process through which students, faculty, staff, and community members who have experienced or witnessed incidents of bias, prejudice, or discrimination against a student can report their experiences to the University's Bias Report and Support System team. For procedures and information on reporting an instance of bias, please visit the Bias Report and Support System page on the Center for Diversity and Inclusion web site. In order to affirm each person's gender identity and lived experiences, it is important that we each ask and check in with others about pronouns. This simple effort can make a profound difference in a person's experience of safety, respect, and support. Please see the Office of the Registrar's Preferred Name page for additional information and resources.


Academic Integrity

Each studio and lab assigned in this course is expected to be completed collaboratively in teams of up to three people (and not more than that), though you are permitted to work individually on any assignment instead, if you prefer. During the scheduled class time and office hours that the instructors are attending, students may be allowed to discuss problems and/or share their screens to show code for purposes of getting help with debugging, illustrating solution approaches that are being discussed, etc., and communication about a particular studio or lab assignment within your team of (3 or fewer) people who are working together on it is allowed at any time. Communication between different teams is not allowed outside of the scheduled sessions that instructors and/or TAs are attending. Student teams may change from assignment to assignment, but the sharing of code between teams without prior permission of the instructor is strictly prohibited, and you must acknowledge and document in detail all contributions that anyone has made to the work.

To encourage you to read the Linux man pages and LPI and LKD text books carefully, you are allowed to use snippets of code from those sources in your studios and labs exams without asking permission, as long as (in comments before and after it) you clearly identify the start and end of each such code snippet and attribute the source from which it came (including page and/or line numbers where those are available). For code from any other sources, including any code or text that is generated by any AI-driven content generator (such as ChatGPT) you must first ask for and receive permission from your professor (and should identify and attribute it similarly if so).

Exams must be completed individually without assistance from any other person, and without reference to external materials except as is specifically allowed by the instructor (documentation of what is allowed will be described in the review lecture, 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 diminished reputation as well as specific sanctions (see below). Cheating also degrades the value of the degree earned by those who complete their work with integrity.

Academic integrity is a serious matter in this course, and the instructor will decide whether any situation of concern in this course warrants referral to the appropriate formal academic integrity adjudication process at the school or university level. If in any doubt, please ask your instructor first.

Academic 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 policies on academic integrity.