Stanley Coulter Hall 239
office hours: MW 2:30pm-3:30pm and by appointment (LWSN 1211)
office hours: M 3:30pm-5pm, W 10:30am-noon (LWSN B132#11)
office hours: T 10:30am-noon, R 4:20pm-5:50pm (LWSN 3133#07)
Duong Ngoc Nguyen
office hours: R 10:30am-noon, F 10:30am-noon (LWSN B116)
PSOs: (HAAS 257)
Operating System Design - The Xinu Approach by Comer; Linksys Version (required)
Operating Systems Concepts by Silberschatz, Galvin and Gagne; latest edition (recommended)
- Please check the TA notes for final exam scores.
- Please check the TA notes for scores and comments on Lab4.
- The final is scheduled on May 1 (Wed), 2013, 3:30-5:30pm, EE 129, closed note/book. The scope of the final is comprehensive, however, most questions will pertain to material covered after the midterm.
- Please check the TA notes for scores and comments of Lab3.
- Please check the TA notes for an update on Lab3.
- Please check the TA notes for instructions on accessing your midterm score. A copy of the midterm and solution: midterm | solution
- The midterm is scheduled on March 8 (Fri), 2013: in-class, closed note/book.
- Please check the TA notes for scores and comments of Lab1.
- Please check the TA notes link for fixing a bug in the sleepms() system call in Lab1.
- As noted in class, the CS 354 midterm is scheduled on March 8, 2013, in-class, closed note/book. The announcement is to facilitate scheduling with further details to follow.
- 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.
- Lab 4
- Lab 3
- Lab 2
- Lab 1
- TA notes (last update: 04/17/2013) li>
- XINU setup (last update: 01/21/2013 )
- Hardware and software documents
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 systems concepts (pp. 8-22, 37-70 from lecture slides)
- Concept of modern computer, hardware v. software, program v. process (pdf)
- Run-time stack of a process and function call convention (pdf)
- Hardware and run-time environment (pp. 96-131 from lecture slides)
- Compiling and running apps in XINU v. UNIX/Linux or Windows
- Hardware and OS support for achieving isolation/protection (pdf)
- XINU simplifications compared to UNIX/Linux, Windows: no isolation/protection -- a) no protection of kernel from processes, b) no protection between processes; x86 hardware support for isolation/protection is not utilized
- Process model (pp. 133-150 from lecture slides)
- XINU process model: no isolation/protection and single heavy-weight process with multiple lightweight processes that possess private run-time stacks but share code and data; hence an app becomes a lightweight process
- Scheduling and context switching (pp. 151-185 from lecture slides)
- Process model and multithreading support: user space, kernel space and hardware support; trade-offs between user and kernel space support; applications (thread packages, JVM)
- Time-share (TS) process scheduling: fairness, CPU- v. I/O-intensive process classification
- Solaris UNIX Dispatch Table Example: TS [dispadmin -c TS -g]
- Multi-level feedback queue and TS scheduling: processing overhead (constant, or O(1), overhead of dequeue and enqueue operations)
- TS scheduling, priority ranges, real-time scheduling classes in Solaris UNIX, Windows, pre-CFS (completely fair scheduler) Linux, BSD UNIX
- Process creation, suspension and resumption in XINU (pp. 186-205 from lecture slides)
- Process coordination and synchronization (pp. 206-257 from lecture slides)
- Mutual exclusion: hardware support (interrupt disabling, tset), software support (semaphore), their trade-offs
- Deadlock management: detection overhead, prevention and semaphore ordering, Ostrich approach adopted by kernels
- Inter-process communication (pp. 264-289 from lecture slides)
- Differentiation of blocking v. nonblocking, synchronous v. asynchronous communication with callback function
- Basic memory management (pp. 290-317 from lecture slides): techniques apply to both kernel and user space
- Memory fragmentation: external, internal; indirection solution, need for hardware support
- Rationale for memory management unit (MMU) hardware support: external fragmentation, simple programming abstraction, hierarchical memory, memory protection for isolation/protection
- Design of modern addressing and memory management support: CPU (including multicores), L1 cache, translation lookaside buffer (TLB), L2 cache, RAM, disk and flash RAM (solid state memories)
- Boundary between virtual and physical memory referencing, interface between hardware and kernel (page fault interrupt and, in some architectures, TLB miss interrupts)
- Virtual memory (pp. 357-387 from lecture slides)
- Role of 2-level page tables (in general, multi-level especially for 64-bit architectures)
- Memory thrashing: Linux example (pdf)
- Device management (pp. 400-423 from lecture slides)
- Basic kernel support for interrupt processing: context borrowing and interrupt stack, common tasks performed by interrupt dispatcher
- Device driver organization (pp. 424-454 from lecture slides)
- Motivation for top half/bottom half subdivision of lower half of modern kernels
- Hardware clocks and kernel time management (pp. 503-543 from lecture slides)
- Tickful v. tickless kernel design
- Delta list, its time update and event insertion costs
- File systems: concepts, UNIX and Xinu file system examples (pp. 577-646 from lecture slides)
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:
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 and Linksys E2100L boxes that will serve 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 4-5 lab assignments. Late days not utilized at the end of the semester will be converted to 25 bonus point 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 10% 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.
It is permissible to discuss a general method of solution 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 method of solution, or to cite the references used. Failure to do so will be considered cheating or plagiarism. The use of "method of solution" means a general discussion of technique or algorithm, such as one would reasonably expect to occur standing in front of a whiteboard, and precludes the detailed discussion of code. Specifically, looking at another student's code on his/her computer monitor is NOT allowed.
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.
All students work is their own. Students who do 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 the class or not. 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 TA 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 Intel x86 machines (32-bit single-core and 64-bit dual-core). 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.