|Room:||Shillman Hall 135|
|Office Hours:||Mondays, 3-5pm|
|Teaching Assistant:||Tinu Gautam|
|TA Office Hours:||Thursdays, 10-12pm, WVH Computer Lab|
|Class Forum:||On Piazza|
Operating systems are one of the foundations upon which the rest of computer science rests. Very rarely do we think twice about starting new processes or threads, dealing with the complexities of memory management, or the vagaries of low-level hardware interactions. Instead, the operating system abstracts these complexities away, leaving us free to work at higher-levels of the software stack.
Understanding the inner-workings of operating systems is a fundamental skill for computer scientists. Whether you are interested in low-level system design, cloud computing, or application developement, the principals of operating system design can help you understand the behavior of computers, and build more performant applications. Furthermore, knowledge of threads, synchronization, and memory management are key for building the large-scale, distributed, data-centric applications of tomorrow.
This course will cover all the basics of operating systems: program loading, context switching, threads and synchronization, virtual memory, and block devices and file systems. We will also cover more advanced topics, such as operating system security and virtualization. This course will be project centric, with students building significant components of an operating system from scratch.
In this course, you will implement the fundamental components of an operating system. This will require writing and debugging low-level code in a Linux command-line environment. Fluency with Linux command line tools (e.g. SSH, gcc, make, gdb, emacs/vim) is therefore a requirement for taking this course.
Students taking this course are expected to be fluent in low-level programming in C. If you are not familiar with managing memory, dealing with pointers, and data structures in C, then you will not be able to complete the assignments in this course. You will also need to debug low-level code, so experience with gdb is recommended.
Students taking this course are expected to have a basic working knowledge of fundamental computer hardware concepts. This includes familiarity with assembly language, memory architectures, and basic device I/O components. You will encounter x86 assembly code within the course projects, and while you are debugging, although you will not be required to write your own assembly code.
The class forum is on Piazza. Why Piazza? Because they have a nice web interface, as well as iPhone and Android apps. Piazza is the best place to ask questions about projects, programming, debugging issues, exams, etc. In order to keep things organized, please tag all posts with the appropriate hashtags, e.g. #lecture1, #project3, etc. I will also use Piazza to broadcast announcements to the class. Bottom line: unless you have a private problem, post to Piazza before writing me/the TA an email.
Schedule, Lecture Slides, and Assigned Readings
|Sept. 3||Intro, PC Hardware, CPUs, and OS Basics||#lecture1||§36||Join Piazza|
|Sept. 10||Processes and Threads||#lecture2||§4, 5, 6, 26, 27||Proj. 1 Out|
|Sept. 17||Synchronization and Deadlock||#lecture3||§28, 29, 30, 31, 32, 103|
|Sept. 24||Scheduling||#lecture4||§7, 8, 9, 10||Proj. 1 Due, Proj. 2 Out|
|Oct. 1||Address Translation and Virtual Memory (with audio)||#lecture5||§13, 15, 16, 18, 19, 20, 21, 22|
|Oct. 8||Memory Management and Garbage Collection||#lecture6||§17|
|Oct. 22||Storage, Disks, and SSDs||#lecture7||§37, 38||Proj. 2 Due, Proj. 3 Out|
|Oct. 29||Files and Directories||#lecture8||§39, 40, 41, 42, 43|
|Nov. 5||Virtual Machine Monitors (with audio)||#lecture9||§101|
|Nov. 12||Authorization and Access Control||#lecture10||Proj. 3 Due, Proj. 4 Out|
|Nov. 19||Exploit Prevention||#lecture11|
|Dec. 3||Final Exam||#final|
|Dec. 8||Proj. 4 Due|
For this class, we will be using the book Operating Systems: Three Easy Pieces.
Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau.
This excellent book is available for free online (all chapters are available as pdfs). You are not required to purchase the textbook, although if you like it (and we think you will) you are encouraged to purchase a copy to help support the authors.
There will be four programming projects throughout the semester. Programming projects are due at 11:59:59pm on the specified date. We will use a turn-in script to create a compressed archive of the project files, timestamp them, and submit them for grading. These projects require significant design and coding, hence students are recommended to start early!
In this class, you will be building key components of the Pintos operating system. Pintos is a small OS developed at Stanford that is specifically designed for teaching OS concepts. Pintos runs inside the QEMU emulator, which will enable you to debug your operating system as it is running. We have installed all necessary software for you on the CCIS Linux machines, although you are welcome to setup Pintos on your own machine as well.
You can get started with Pintos by looking at the documentation here. The Introduction section explains how to setup your environment and run Pintos on the CCIS Linux machines. All of the documentation for the four projects is also available from the Pintos docs.
|Assignment||Slides||Description||Due Date||Piazza Tag|
|Project 1||Slides||Threads||September 24||#project1|
|Project 2||Slides||User Programs||October 22||#project2|
|Project 3||Virtual Memory||November 12||#project3|
|Project 4||File Systems||December 8||#project4|
You will form groups of three people to do the projects. I will allow you to form your own groups; if you are having trouble finding a partner, post a notice to Piazza. As you are free to choose your partners, I will not be sympathetic to complaints at the end of the semester about how your group-mates did not do any work. All group members should be involved in all major design decisions, and groups should develop a programming plan that can be effectively parallelized. You may switch groups between programming projects.
There will be one midterm and one final. All exams will be closed book and closed notes, and computers are not allowed nor is any access to the Internet via any device. The exams will cover material from lectures, readings, and the projects. The final will be cumulative, so review everything!
|Projects:||15% each (60% total)|
Each project will include a breakdown of how it will be graded.
To calculate final grades, I simply sum up the points obtained by each student (the points will sum up to some number x out of 100) and then use the following scale to determine the letter grade: [0-60] F, [60-62] D-, [63-66] D, [67-69] D+, [70-72] C-, [73-76] C, [77-79] C+, [80-82] B-, [83-86] B, [87-89] B+, [90-92] A-, [93-100] A. I do not curve the grades in any way. All fractions will be rounded up.
Requests for Regrading
In this class, we will use the Coaches Challenge to handle requests for regrading. Each student is allotted two (2) challenges each semester. If you want a project or a test to be regraded, you must come to the professors office hours and make a formal challenge specifying (a) the problem or problems you want to be regraded, and (b) for each of these problems, why you think the problem was misgraded. If it turns out that there has been an error in grading, the grade will be corrected, and you get to keep your challenge. However, if the original grade was correct, then you permanently lose your challenge. Once your two challenges are exhausted, you will not be able to request regrades. You may not challenge the use of slip days, or any points lost due to lateness.
Note that, in the case of projects, all group members must have an available challenge in order to contest a grade. If the challenge is successful, then all group members get to keep their challenge. However, if the challenge is unsuccessful, then all group members permamently lose one challenge.
For programming projects, we will use flexible slip days. Each student is given four (4) slip days for the semester. You may use the slip days on any project during the semester in increments of one day. For example, you can hand in one project four days late, or one project two days late and two projects one day late. You do not need to ask permission before using slip days; simply turn in your assignment late and the grading scripts will automatically tabulate any slip days you have used.
Slip days will be deducted from each group member's remaining slip days. Keep this stipulation in mind: if one member of a group has zero slip days remaining, then that means the whole group has zero slip days remaining.
After you have used up your slip days, any project handed in late will be marked off using the following formula:
Original_Grade * (1 - ceiling(Seconds_Late / 86400) * 0.2) = Late_Grade
In other words, every day late is 20% off your grade. Being 1 second late is exactly equivalent to being 23 hours and 59 minutes late. My late policy is extremely generous, and therefor I will not be sympathic to excuses for lateness.
Projects must be entirely the work of the students turning them in, i.e. you and your group members. Copying code from other students (past or present) or websites is strictly prohibited. All project code submitted by students will be scanned by plagiarism detection software. If you have any questions about using a particular resource, ask the course staff or post a question to the class forum.
All students are subject to the Northeastern University Academic Integrity Policy. All cases of suspected plagiarism or other academic dishonesty will be referred to the Office of Student Conduct and Conflict Resolution (OSCCR).
Accomodations for Students with Disabilities
If you have a disability-related need for reasonable academic accommodations in this course and have not yet met with a Disability Specialist, please visit www.northeastern.edu/drc and follow the outlined procedure to request services. If the Disability Resource Center has formally approved you for an academic accommodation in this class, please present the instructor with your "Professor Notification Letter" during the first week of the semester, so that we can address your specific needs as early as possible.