office hours: M 9:45-10:45am, W 10:15-11:15am, and by appointment (LWSN 1211)
Teaching Assistants: (HAAS G50)
firstname.lastname@example.org; M 10:30-11:30am, T 4:30-5:30pm
email@example.com; F 9:30-11:30am
firstname.lastname@example.org; W 1:30-3:30pm
email@example.com; T 1:30-3:30pm
firstname.lastname@example.org; R 1:45-3:45pm
PSOs: (HAAS 257)
M 11:30-1:20pm (McKee)
M 1:30-3:20pm (Sruthi)
M 3:30-5:20pm (Sruthi)
T 11:30-1:20pm (Lin)
W 11:30-1:20pm (Lin)
W 3:30-5:20pm (Ogg)
R 11:30-1:20pm (McKee)
R 3:30-5:20pm (Ogg)
F 11:30-1:20pm (Songhela)
F 3:30-5:20pm (Songhela)
Operating System Design – The Xinu Approach, Douglas Comer, latest edition (required)
Operating Systems Concepts by Silberschatz, Galvin and Gagne; latest edition (recommended)
- No PSOs but regular office hours during 04/23-04/27.
- The final is scheduled on May 3, 2018; 3:30-4:30pm, STEW 130. It is a 1-hour exam, closed book/note. Please make sure to bring your Purdue ID. Scope of the exam is comprehensive with emphasis placed on material covered after the midterm. Sample exam and solution.
- Lab5 has been graded. Please follow the same procedure as before to check your scores (lab5.rpt) and follow up.
- Lab4 has been graded. Please follow the same procedure as before to check your scores (lab4.rpt) and follow up.
- Lab3 and the midterm have been graded. Please follow the same procedure as before to check your scores (lab3.rpt and mid.rpt) and follow up. Come by my office hours to pick up your exam. Copy of midterm and solution.
- The midterm is scheduled on Mar. 2, 2018; in-class, closed book/note. It is a 40 minute exam. Please make sure to bring your Purdue ID. The scope of the exam includes the material covered up to (and inclusive) 02/28/2018. Sample exam and solution.
- Lab2 has been graded. Please follow the same procedure as lab1 to check your scores (lab2.rpt) and follow up.
Lab1 has been graded. The scores have been posted at
in file lab1.rpt where username is your login name. lab1.rpt is a plain ASCII text file. As noted in class, outside of the TAs and the instructor, only the person with the specified username can read the files in the directory. If you have any questions, please send email to the TAs (specified in lab1.rpt) who graded the respective problems. For questions related to Problem 3.4, please check the TA notes which contain additional instructions.
- No PSOs in weeks 1 and 2 of class. Although not required, it is strongly recommended that students attend the PSOs where lab assignments are discussed and TA assistance is provided.
- Lab6 (html)
- Lab5 (html)
- Lab4 (html)
- Lab3 (html)
- Lab2 (html)
- Lab1 (html)
- TA Notes (html)
- XINU set-up: how to configure, compile, load and run XINU (html)
Please follow instructions given in class for accessing lecture slides. The topics listed below include material not covered in the pdf lecture slides. They should be referenced from class notes.
- What is CS 354 about? (pdf)
- Operating system concepts and background
- Systems programming and architecture review, CPU instruction set, registers, main memory, programs, compilers, assembly and machine code
- Memory layout produced by C compilers, run-time stack and CDECL caller/callee convention (pdf)
- Isolation/protection: motivation, general architecture (hardware and software support), x86 specific implementation features
- Effect of x86 isolation/protection and segmentation support on XINU
- Kernels as reactive systems: roles of upper and lower halves
- Sequence of events that lead to invocation of scheduler; example in XINU involving sleepms() and clock interrupt handling
- Time-share (TS) process scheduling: fairness, CPU- versus I/O-bound process classification
- Fair scheduling, implementation issues, and logarithmic scheduling overhead
- Solaris UNIX Dispatch Table example: TS [dispadmin -c TS -g]
- Multi-level feedback queue and constant scheduling overhead
- Hardware/software support for process coordination/synchronization and their trade-offs
- Deadlocks: why they arise, detection overhead, prevention, and approach followed by modern kernels and its rationale
- Meaning of synchronous/asynchronous and blocking/non-blocking IPC (and I/O in general)
- Asynchronous IPC with callback function and implementation issues to preserve isolation/protection
- Zero-copy I/O: kernel support to reduce file server copy and system call overhead
- External and internal fragmentation, hardware support for address translation, other benefits of memory virtualization
- Memory hierarchy, cache misses and boundary between hardware and kernel responsibility
- Worst-case memory access latency, aliasing and context-switch overhead, pros/cons of paging
- Page replacement policies: optimal (offline Belady), LRU, global clock, and their relationship
- Motivation for multi-level page tables and memory savings: few elephants | many mice
- Multilevel page tables to reduce page table size: 2-level example
- Memory thrashing: what it is, symptoms (page fault rate, CPU utilization), and solutions
- Linux example (pdf)
- Why kernel synchronization mechanisms for IPC extend to device I/O
- Organization of lower half into top and bottom halves: motivation and their roles
- Two approaches for implementing the bottom half and their pros/cons
- Role of DMA hardware support in isochronous video/audio streaming, its benefit, and integration in the lower half
- Three types of hardware clocks and their function
- Tickful vs. tickless kernels, their pros/cons
- Overhead associated with delta list when performing lower half and upper half kernel operations in XINU
CS 250, 251, 252. Ability to understand and write complex programs in C. Familiarity with system development tools.
The grade will be determined by a midterm, final, and lab assignments. Their relative weights are:
The exams and lab assignments will have bonus problems. Bonus points are confined to each component (midterm, final, lab). For example, bonus points from the midterm help achieve the 25% contribution of the midterm but do not carry over to the final or lab components.
Labs and Policies:
We will use the XINU operating system for the lab assignments. The XINU lab is located in the HAAS Building Room 257. The lab houses dedicated backend machines used for implementation, testing, and performance evaluation. They include Intel x86-compatible Galileo boards equipped with Quark X1000 processors. We will use x86 backends and frontends as our implementation platform.
Getting your CS account.
Students registered in the course should have an account automatically set up. Please check by going to HAAS 257 and logging in to one of the frontend machines (Linux PCs). If you have registered up but don't have an account, please contact email@example.com.
To help manage unexpected scheduling demands, you are given a budget of 3 late days in total that may be used for late submissions of lab/homework assignments. For example, you may submit 1 day late on three lab assignments, or 3 days late on one lab assignment. Any combination is valid as long as the total days delayed does not exceed 3. There will be a total of 6 lab assignments. Late days not utilized at the end of the semester will be converted to 25 bonus points each (maximum of 75).
Due to the low-level systems nature of the lab assignments, coding and evaluating parts of an operating system running on hardware is time intensive. To encourage proactive handling of assignments, all submissions turned in 2 days prior to its deadline will be given a 7% bonus credit (as a fraction of the points received).
We wish to foster an open and collegial class environment. At the same time, we are vigorously opposed to academic dishonesty because it seriously detracts from the education of honest students. Because of this, we have the following standard policy on academic honesty, consistent with Purdue University's official policy.
All CS354 lab assignments are individual efforts and collaboration is not allowed. It is permissible to discuss general ideas with other students, or to make use of reference materials in the library or online. If you do this, you will be expected to clearly disclose with whom you discussed the ideas, or to cite the references used. Failure to do so will be considered cheating or plagiarism. Collaboration that entails discussing specific methods of solution is not allowed. This includes discussing and sharing of code.
Unless otherwise explicitly specified, all code that is submitted is to be entirely each student’s own work. Using any code or copying any assignment from others is strictly prohibited without advance prior permission from the instructor. This includes the use of code others have submitted in the past.
Students who share their work with others are as responsible for academic dishonesty as the student receiving the material. Students are not to show work to other students, in class or otherwise. Students are responsible for the security of their work and should ensure that printed copies are not left in accessible places, and that file/directory permissions are set to be unreadable to others (e.g. use "chmod -R 700 *" from your home directory). If you need assistance protecting your work, please contact the TAs or the instructor.
Students who encourage others to cheat or plagiarize, or students who are aware of plagiarism or cheating and do not report it are also participating in academically dishonest behavior.
Be aware that we will use a software tool called MOSS to check for copying among submitted assignments. Additionally, the instructor and TA will be inspecting all submitted material to ensure honesty.
Any case of academic dishonesty will be dealt with by a severe grade penalty in the overall class grade and referral to the Office of the Dean of Students.
In the event of a major campus emergency, course requirements, deadlines, and grading percentages are subject to changes that may be necessitated by a revised semester calendar. If such unusual circumstances arise, students may determine any such changes by contacting their instructors via email or phone, and checking the course web page for updates.
Emergencies and campus closings will be announced on local media and on the main Purdue University WWW site http://www.purdue.edu. Individuals may subscribe to an SMS text announcement service. Other details are on the Purdue emergency preparedness site.
This is an undergraduate introductory course to operating systems that investigates how modern operating systems are architected and implemented. Extensive implementation experience is gained by coding, testing, and benchmarking key components of the XINU operating system on dedicated backend hardware. Our main implementation platform will be x86-compatible backend machines and Intel x86 frontend PCs where code is developed. Most coding is done in C, with some hardware dependent components utilizing assembly language.
The topics covered in the course include: evolution of computing systems and their operating systems, process management, inter-process communication, memory manangement, virtual memory, I/O subsystems and device management, file systems, virtualization and security, and mobile operating systems. In addition to implementing key OS features in XINU, we will examine case studies in Linux, UNIX (Solaris and BSD), and Windows that differ from XINU and each other in significant ways. One important example is how I/O subsystems are architected to handle a range of heterogenous devices and their interrupts, including high-speed USB and wired/wireless network interfaces, that characterize many of today's computing systems. Kernel dependence on changing hardware features and support is an important theme throughout the course that will help familiarize with recent developments such as non-traditional file systems for flash memory prevalent in mobile systems. We will touch upon mobile OS (e.g., iOS, Android) with emphasis on differences with desktop/server operating systems.