|Instructors||Chris Gill (office hours by appointment)|
|Marion Sudvarg (office hours by appointment)|
|Course Web Site||https://classes.engineering.wustl.edu/cse522/|
|Course Piazza Page||https://piazza.com/wustl/spring2022/sp2022e81cse522s01/home|
|Course Meetings||Tuesdays and Thursdays 2:30 - 3:50 PM in Urbauer 216.|
||Thu, Feb 24th, 2:30 - 3:50 PM in Jubel 121
||Tue, Apr 19th, 2:30 - 3:50 PM in Lopata 103
|Prerequisites||CSE 422S (Operating Systems) and C/C++ programming experience are firm prerequisites for this course.|
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 (including the addition of entirely new material on containers and virtualization). Hiccups are to be expected, and finding new and exciting ways to break course exercises is encouraged, as the instructors continue to fine-tune the content and scope of each class meeting.
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 lwn.net. 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.
|1||Tue, Jan 18th||Course Introduction
Setting up the Raspberry Pi
|2||Thu, Jan 20th||Hardware Performance Monitoring and Kernel Modules||
||Hardware Counters and Loadable Kernel Modules|
|3||Tue, Jan 25th||Filesystem Monitoring and Events||
||Observing File System Events|
|4||Thu, Jan 27th||Process Observability and Isolation||
|5||Tue, Feb 1st||Isolation with Namespaces||
||Isolation with Namespaces
Course Project Assigned
|6||Thu, Feb 3rd||User Namespaces and Capabilities||
||Capabilities and User Namespaces|
|7||Tue, Feb 8th||Subsystem Observability and Control Groups
Course Project Overview and Ideas
||Observing Memory Events|
|8||Thu, Feb 10th||Timing Forensics and CPU cgroups||
||CPU Control and Timing Events
Project proposals due Fri, Feb 11th at 11:59PM
|9||Tue, Feb 15th||Timers and Interrupts||
||No Studio Assigned – Catch-Up Day|
|10||Thu, Feb 17th||I/O Cgroups||
||Controlling I/O Behavior
Project proposal feedback returned by Fri, Feb 18th at 11:59PM
|11||Tue, Feb 22nd||First Exam Review in Urbauer 216||All studios assigned so far are due Wed, Feb 23rd at 11:59pm|
|12||Thu, Feb 24th|
|13||Tue, Mar 1st||Introduction to Docker||
||Introduction to Docker Containers and Images
Revised project proposals due Tue, Mar 1st at 11:59pm
|14||Thu, Mar 3rd||Docker Container Management||(optional) DKR pages 70-83, 85-110, 115-130, 134-138, & 141-142||Container Control with Docker|
|15||Tue, Mar 8th||Network Namespaces||
||No Studio Assigned – Catch-Up Day|
|16||Thu, Mar 10th
||Docker Communication and Networking||
||Docker Web Applications|
|17||Tue, Mar 22nd||CPU Virtualization||No Studio Assigned – Catch-Up Day|
|18||Thu, Mar 24th||Memory Virtualization||
||Virtual Machine Performance with QEMU and KVM|
|19||Tue, Mar 29th||I/O Virtualization||virtio: Towards a De-Facto Standard For Virtual I/O Devices||No Studio Assigned – Catch-Up Day|
|20||Thu, Mar 31st||Project Milestone Demos in Urbauer 216
Project milestone code and reports are due Friday, Apr 1st at 11:59pm
|21||Tue, Apr 5th||Device I/O||
||No Studio Assigned – Catch-Up Day|
|22||Thu, Apr 7th||Device Memory Interaction||
|23||Tue, Apr 12th||Device Ecosystem||No Readings Assigned||No Studio Assigned – Catch-Up Day|
|24||Thu, Apr 14th||Second Exam Review in Urbauer 216||All studios assigned after the First Exam are due Mon, Apr 18th at 11:59pm|
|25||Tue, Apr 19th|
|26||Thu, Apr 21st||In-class project time|
|27||Tue, Apr 26th||Project Presentations I in Urbauer 216|
|28||Thu, Apr 28th||Project Presentations II in Urbauer 216
All project code and reports are due Monday, May 2nd at 11:59pm
The course project will give each team of two or three students an opportunity to propose and complete their own significant extension of, or modification to, system software based on 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 the project.
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:
The project will be evaluated in part based on a live presentation at the end of the semester, as well as code and documentation which will be submitted and graded both at an interim point in the semester and at the end of the semester. The presentation and writeup 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).
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 FAQWhat if your Pi is freezing up? Leaving your Pi at home
Generating SSH Keys
Using Visual Studio Code Remotely
To be able to complete the studio assignments this semester, you will need to purchase a CanaKit Raspberry Pi 3 B+ kit (or, if not available, a CanaKit Raspberry Pi 4 B kit), which is the platform on which we have tested out our solutions to those assignments, and on which we will be grading them.
Kits may be purchased 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 will need to additionally purchase a Micro-HDMI to HDMI adapter. You do not need this if you are using a Raspberry Pi 3 this semester. We recommend the following adapter:
If you so desire, you may set up your Raspberry Pi in your home or office and configure it for remote access. However, the instructors 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.
The in-class studios and assigned readings 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, KVM, or Docker source. Exams will not have questions derived from the source (though basic concepts and pseudo-code are fair game). However, the Linux, KVM, and Docker implementations each constitute huge sets of deeply interdependent source code files. The only way you will ever understand them in-depth is by looking through them many times.
There are two required course textbooks for this course:
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 two optional additional course textbook also will be suggested:
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).
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.
The C Programming Language (2nd Edition) by Brian W. Kernighan by Dennis M. Ritchie gives a terse but reasonably complete coverage of the C language and its libraries.
The C Pocket Reference (1st Edition) by Peter Prinz and Ulla Kirch-Prinz is a good but somewhat more concise reference for basic C topics.
The Bootlin Elixir Cross Referencer allows you to search different releases of the Linux kernel source code to find files, symbols, etc. For the 5.10.17 version of the Linux kernel that we'll be using this semester, the direct link is https://elixir.bootlin.com/linux/v5.10.17/source.
An additional resource for up-to-date kernel documentation is the kernel.org documentation website. It contains documentation from the Linux source code's Documentation directory in a nicely formatted, searchable medium.
The manual pages that are installed with Linux
are a great source of information about different functions and variables
you'll be using in studio assignments.
In a terminal window on your Raspberry Pi or on
or on one of the Linux lab machines, you can issue the command
to see more about those manual pages, or issue the appropriate
command that's listed in the assigned readings in the course syllabus, to see a specific manual page.
Most manual pages referenced in this course, and many others, are also available online at the Linux man pages online website, maintained by Michael Kerrisk (the author of the LPI textbook).
Once you have installed linux on your Raspberry Pi, the user
space library header files in the
on it are worth looking through in an editor of your choice, to see
the declarations of various functions and variables that also are
shown in the relevant
man pages we've assigned in the readings. Emacs (you may
need to run
sudo apt-get install emacs to obtain and
install it on your Raspberry Pi) is one good general purpose editor
that also can be used to run
gdb and other useful tools
from within it.
Operating Systems: Three Easy Pieces by Arpaci-Dusseau and Arpaci-Dusseau is a good introduction to operating systems, without all the complexities of Linux.
Understanding the Linux Kernel by Bovet and Cesati, 2006. This is a more exhaustive reference to the kernel than the course textbook, covering many data structures and code snippets in detail. Available online for free through the university's subscription to the O'Reilly Safari service .Washington University Patrons can log in by clicking "Not listed? Click here." On the next log in page, enter your WUSTL email.
Linux Device Drivers by Corbet, Rubini, and Kroah-Hartman, 2005. This book covers a topic that we will not go into in detail, but contains some useful reference material over kernel modules, kernel development, kernel locking, timing, and other topics. Available online for free through lwn.net.
LWN.net is a news and information outlet for the open source community. They often run very high quality articles about kernel development, kernel architecture, and kernel mechanisms. When I have trouble finding a good online resource, a search for "lwn.net (my_topic)" often yields good results. However, beware of out-of-date material.
Linux Journal is a magazine covering the Linux community. They often run very high quality articles about kernel development, kernel architecture, and kernel mechanisms. Similar to above, searching for "Linux Journal (my_topic)" often yields good results. As above, beware of out-of-date material.
Tutorials on the Linux Journey web site (especially those in the "Grasshopper" section but also possibly some in the "Journeyman" section) may be helpful to brush up on using the Linux command-line environment.
There are three activities for which you will receive credit in this course: studios, 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). The course project requires that students propose and complete a novel kernel modification, and students will be graded on a project proposal; an initial milestone that includes a presentation, code, and writeup describing progress so far; and on their final project submission. Two in-semester exams will evaluate your technical understanding of course concepts.
Your grade will be determined as follows:
|Course Project Proposal||10%|
|Course Project Milestone||15%|
|Course Project Final Submission||25%|
Especially with the challenges many students may face in an on-line learning environment, 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 email@example.com 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, projects, and/or exams.
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 firstname.lastname@example.org. 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 email@example.com 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 University's Pronouns Information page and the Office of the Registrar's Preferred Name page for additional information and resources.
Each studio and project assigned in this course is expected to be completed in teams of up to three people (and not more than that) – we want to encourage collaborative work though you are also allowed to work by yourself if you prefer. During the regularly scheduled class times that the instructors are attending (and only during those times), all students are allowed to 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 project 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 class times that the instructors are attending unless the instructors give permission in advance. Student teams may change from assignment to assignment, but the sharing of code between teams without prior permission of the instructors 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 the LPI, LKD, LSP, and DKR text books carefully,
you are allowed to use snippets of code from those sources in your studios, projects, and 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 you must first ask for and receive permission from your instructors (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 first. Anyone found to have cheated or to have helped someone else cheat will face penalties that may include receiving a negative score equal in magnitude to the value of the assignment in question (e.g., cheating on an assignment worth 10% of the course grade would result in -10% being assigned for a total loss of 20% from the course grade, which is twice as large a loss as simply not turning in the assignment).
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 undergraduate and graduate policies on academic integrity.