We've missed a bunch of classes due to snow days. See the Snow Day page for details.
|Instructor||Nat Tuck; firstname.lastname@example.org|
|Room||Shillman Hall 220|
|Time||Monday, 6pm - 9pm|
|Instructor Office Hours||Wednesdays @ noon - 2pm|
|TA||Sai Kulkarni; email@example.com|
|TA Office Hours||Wednesdays, 4-6pm @ 362 WVH|
In this course you will be learning what an operating system is, what it does, and how it works. Unless you're working on a very simple embedded microcontroller, every program you write will run on some operating system and rely on it for basic services like memory allocation, thread and process scheduling, access to a file system, networking, and many other things. Having some idea of how an operating system does these things is useful.
Thanks to Prof Christo Wilson for the course materials and course page text.
In the projects for this course, you will implement many of the core features of an operating system. This will require writing and debugging low level code in a Linux command-line environment. You should be familiar with ssh, gcc, make, and an editor like emacs or vim.
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 - including x86 assembly - so experience with gdb is recommended.
Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau.
The book is available online, but buying a copy is not a bad idea.
|Jan 12||Intro; PC Hardware, CPUs, and OS Basics||ch. 36||-|
|Jan 19||MLK Jr's Birthday, no class||-||-|
|Jan 26||Processes and Threads||ch. 4, 5, 6, 26, 27||(snow day)|
|Feb 02||Synchronization and Deadlock||ch. 28, 29, 30, 31, 32, 103||(snow day)|
(Processes & Threads)
|ch. 7, 8, 9, 10||
Proj 1 out; Proj 2 out
|Feb 16||Presidents' Day, no class||-||-|
Address Translation and Virtual Memory
(Sync & Deadlock; Scheduling)
|ch. 13, 15, 16, 18, 19, 20, 21, 22||Proj 1 due (Sunday the 22nd)|
(Make-up Lecture: Address Translation & Virtual Memory, Free Space & GC)
|Mar 09||Spring break, no class||-||-|
Memory Management and Garbage Collection
(Garbage Collection; Storage, Disks, and SSDs)
|ch. 17||Proj 2 due; Proj 3 out|
||ch. 37, 38||-|
|Mar 30||Files and Directories||ch. 39, 40, 41, 42, 43||Proj 3 due; Proj 4 out|
|Apr 06||Virtual Machine Monitors, Authorization and Access Control||ch. 101||-|
|Apr 13||Exploit Prevention||-||-|
|Apr 20||Patriot's day, no class||-||-|
|Apr 27||Final Exam||-||Proj 4 due|
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. 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.
You can download a tarball of pintos.
|Project 1||Slides||Threads||Feb 16|
|Project 2||Slides||User Programs||Mar 16|
|Project 3||Slides||Virtual Memory||Mar 30|
|Project 4||Slides||File Systems||Apr 27|
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!
Each project will include a breakdown of how it will be graded.
In this class, we will use a variant of the Coach's 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 20% for each day late or fraction thereof. Being one second late is the same as being 23 hours late.
This late policy is extremely generous. Make sure to save your slip days for when you really need them - they're all you get.
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).
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.