Engineering.wustl.edu

E81 CSE 422S: Operating Systems Organization

Fall 2019

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 and Brian Kocoloski.


Instructor Chris Gill (Office Hours in Jolley Hall 518: by appointment)
Teaching Assistants
Noah Goldstein -- Office hours Thursdays 9 PM to 10 PM and Fridays 1 PM to 3 PM in Urbauer 218
Fangchen Li -- Office hours Fridays 4 PM to 6 PM, and Sundays 2 PM to 4 PM in Urbauer 218
Uki Malla -- Office hours Fridays 11:00 AM to noon in Urbauer 218
Sam Westerman -- Office hours Fridays 9 AM to 9:50 AM in Urbauer 218
Course Web Site http://www.cse.wustl.edu/~cdgill/courses/cse422_fl19/
Piazza Page https://piazza.com/wustl/fall2019/cse422s/home
Course Meetings Mondays and Wednesdays 8:30am - 9:50am in Urbauer 218 (please note that under Washington University's new policy regarding course meeting times, each class meeting will start precisely at 8:30am and finish precisely at 9:50am). Most days will start with lectures and discussions followed by assisted group work on studios and/or labs.
Exam 1
Wednesday October 9th, 8:30am in Jubel Hall Room 121
Exam 2
Wednesday December 4th, 8:30am in Jubel Hall Room 121
Prerequisites CSE 361S, or graduate student standing and C/C++ programming experience
CSE 362M is encouraged but not required
CSE 332S/504N is encouraged but not required

Contents
  1. Course Description
  2. Prerequisites
  3. Discussions/Studios
  4. Lab Projects
  5. FAQ/Tips
  6. Textbooks and Other Resources
  7. Grading
  8. Accessibility
  9. 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 instructor pursues ongoing refinement of the content and scope of this course.


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. If any changes are made to this schedule, students will be notified both in class and through e-mail, 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 Mon, Aug 26th Academic Integrity
Course Introduction
Code Pointers
C Practice Exercises
Building the Linux kernel
2 Wed, Aug 28th Setting up the Raspberry Pi 3 LKD chapters 1,2
LPI chapters 1-3
Setting up the Raspberry Pi 3
Mon, Sep 2nd: Labor Day - no classes
3 Wed, Sep 4th How and when does the kernel run? LKD chapter 5
Userspace / Kernelspace API Split
Code Pointers
Creating a syscall
4 Mon, Sep 9th Time sources and timing LKD chapter 11
LPI chapter 23
High Resolution Timers Subsystem
Description of the Timer Wheel System
Introduction of hrtimer Patch (Formerly ktimers)
Code Pointers
Userspace benchmarking
5 Wed, Sep 11th Kernel tracing Ftrace overview document
Kernelshark
Code Pointers
Tracing with ftrace and Kernelshark
6 Mon, Sep 16th Structure and infrastructure of the Linux kernel LKD chapter 6 and pp. 337-348 Writing a kernel module

Lab 1 Assigned (due Wed, Oct 2nd at 11:59PM)
7 Wed, Sep 18th Processes LKD chapter 3
LPI chapters 24-26
Code Pointers
Process Family Tree
8 Mon, Sep 23rd Traditional process scheduling LKD chapter 4
LPI chapter 35
Completely Fair Scheduling
9 Wed, Sep 25th Real-time process scheduling Deadline Scheduling vs POSIX Real-time Scheduling Real-time Scheduling
10 Mon, Sep 30th Interrupts and interrupt handlers LKD chapter 7
Software Interrupts and Real-time
In-class lab (or studio catch-up) time
11 Wed, Oct 2nd Top half / bottom half processing LKD chapter 8 In-class lab (or studio catch-up) time

Lab 1 due Wed, Oct 2nd at 11:59PM
12 Mon, Oct 7th Exam 1 Review All studios assigned so far are due Tue, Oct 8th at 11:59PM
13 Wed, Oct 9thExam 1 (8:30am in Jubel Hall Room 121)
Mon, Oct 14th: Fall Break - no classes
14 Wed, Oct 16th Kernel synchronization I

Overview of the Lab 2 Assignment
LKD chapter 9 In-class lab time

Lab 2 Assigned (due Wed, Nov 6th at 11:59PM)
15 Mon, Oct 21st Kernel synchronization II LKD chapter 10

What is RCU, fundamentally?
Kernel Reference on RCU
Synchronizing Threads in the Kernel
16 Wed, Oct 23rd Userspace synchronization LPI chapters 30 and 31

Read these man pages (run these commands) on a Linux machine:
man 7 futex
man 2 futex
Build Your Own Locks
17 Mon, Oct 28th Virtual memory and paging In-class lab (or studio catch-up) time
18 Wed, Oct 30th Kernel memory LKD chapter 12 Kernel memory management
19 Mon, Nov 4th
Guest Lecturer: Brian Kocoloski
Address spaces / shared memory LKD chapter 15

Read these man pages (run these commands) on a Linux machine:
man 2 mmap
man 3 shm_open
Shared memory management
20 Wed, Nov 6th
Guest Lecturer: Brian Kocoloski
Program execution, linking, layout The inside story on shared libraries and dynamic loading In-class lab (or studio catch-up) time

Lab 2 due Wed, Nov 6th at 11:59PM
21 Mon, Nov 11th Virtual filesystem

Overview of the Lab 3 Assigment
LKD chapter 13 VFS layer

Lab 3 Assigned (due Fri, Dec 6th at 11:59PM)
22 Wed, Nov 13th Inter-process communication: signals LPI chapters 20-22
man 7 signal
man sigaction
man 2 write
Linux Signals
23 Mon, Nov 18th Inter-process communication: pipes, fifos, and sockets LKD pp. 29-33 and 38-40
LPI chapters 43-44, 56-59 man 2 pipe
man 2 read
man 2 write
man 3 mkfifo
The LPG Pipes and FIFOs pages
man 2 bind
man 7 unix
man 7 ip
Linux Pipes, FIFOs, and sockets
24 Wed, Nov 20th I/O multiplexing mechanisms LPI chapter 63 I/O event handling
25 Mon, Nov 25th No lecture or assigned readings: in-class lab (or studio catch-up) time
Wed, Nov 27th: Thanksgiving Break - no classes
26 Mon, Dec 2nd Exam 2 Review in Urbauer 218 All studios since the first exam are due Tue, Dec 3rd at 11:59PM
27 Wed, Dec 4thExam 2 (8:30am in Jubel Hall Room 121)

Lab 3 due Fri, Dec 6th 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 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 timestamps on Box) 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.

The following labs have been assigned so far:

  • Lab 1 (due Wed, Oct 2nd at 11:59PM)

    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


    Textbooks and Other 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 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 this, there is no substitute for reading source code. Some of the lectures and studios will come with pointers to relevant source code files, and for overall understanding it is expected that students will spend 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 it many times.

    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 understanding of kernel design, written with the depth of a kernel veteran.

    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 an expert Linux veteran.

    There are a number of other useful references. 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. Please also note that the Linux kernel is frequently (and often rapidly) updated, so that while the general information in the textbooks is correct, details of the source code itself, the names of source code files, and where those files exist, are somewhat likely to change.

    Students will need 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 work on them there. Monitors, keyboards, mice, and cables will all be provided in the lab for this purpose - students will need to provide the Raspberry Pi 3 and a power cord.

    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 at certain points we will be 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 may require an X11 window, so simple ssh access will not necessarily be enough to do everything remotely.


    Grading

    There are three activities for which you will receive credit in this course: studios, labs, and exams. 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 lab assignments will ask you to apply general course concepts and analyze and implement design alternatives. The exams will evaluate your technical understanding of course concepts.

    Your grade will be determined as follows:

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

    Accessibility

    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 (http://disability.wustl.edu), potentially including accommodations for studios, labs, and/or exams.

    Academic Integrity

    Each studio and lab assigned in this course is expected to be completed collaboratively by up to three people (and not more than that). 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.

    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 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 anyone found to be cheating or helping someone else cheat will receive 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). The instructor will determine what constitutes cheating in this course. If in any doubt, please ask 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 undergraduate and graduate policies on academic integrity.