Welcome to your first course on operating systems! This course will introduce you to an exciting range of materials from the broad field of operating systems, including basic operating system structure, process and thread synchronization and concurrency, file systems and storage servers, memory management techniques, process scheduling, resource management, a few other hot topics.
This course assumes familiarity with basic computer organization (e.g., processors, memory, and I/O devices as covered in CMSC 15400) and data structures (e.g., stacks and hash tables). You will need to be able to program in C (not C++, and definitely not Java) to perform the assignments in the course. You should have enough background of C programming from your previous courses. CMSC 15400 and a working knowledge of the C programming language are strict prerequisites of this course. Students who have not taken CMSC 15400 must speak with the instructor to ascertain that they meet the prerequisites for this course.
If you are interested in learning the history of operating systems you can read my slides or here.
The class website is:
Full link: http://www.classes.cs.uchicago.edu/archive/2014/fall/23000-1/
Shorter link: http://goo.gl/bVaf5Z
This "Class Overview" website is located here: http://www.classes.cs.uchicago.edu/archive/2014/fall/23000-1/about/all.html
Many documents (e.g. lecture notes, project hints) from the course website are only accessible from uchicago.edu domain. If you want to access the documents from outside the campus network, please use the University's VPN (see https://itservices.uchicago.edu/services/vpn-cvpn).
Another way is the old school approach: ssh to a CSIL machine, run wget, and then scp the file to your laptop.
For mailing list, we will use Piazza. If you do not see any emails from Piazza by the end of the first week, please let me know ASAP. It is your job to check class emails frequently and carefully. I strongly suggest you disable the "digest mode" in Piazza and enable the direct mode so you can directly receive any email that is recently posted.
You are NOT allowed to post any project solutions or code snapshots in Piazza. If you have problems with your project, please talk to the TA.
All questions about the project can be posted on Piazza. Do NOT write email to my or the TA's email address because your email won't be tracked. If I or the TA need to interact with you more frequently (e.g. to solve your project problem), then we will let you know when we can start using direct email addresses. But if we don't tell you, everything should go to Piazza.
In Piazza, you can see that I have created some tags (e.g. p1, p2, lectures, etc.). Please post your email with the appropriate tag. Otherwise, there is a chance that your email is not tracked properly.
There will be a midterm and a final exam (non cumulative), 4 projects, but no homework assignments and no quizzes.
The midterm and final are closed book and no cheat sheet, so the most important thing you need to do is to come to and understand the lectures. The content of midterm and final will come mostly from lectures.
The class meets two times a week for lectures.
Quite often I make the class interactive by asking some questions. If you participate quite frequently, this can help your grades, especially if your grade is on the borderline. For example, if you have the highest grade in the B+ group (slightly below A-) and you participate a lot in class, there is a big chance that your grade can change to A-.
Overall, don't be shy to interrupt me in the middle of my lectures! I welcome any questions you have.
The grading policy should be listed on the course homepage.
The class will be curved (for your benefits). In the past, curve leads to better grades.
This course has one required book:
Operating Systems: Three
Easy Pieces (OSTEP).
This book is free! Thanks to Prof. Remzi and Andrea
Arpaci-Dusseau at UW-Madison!
If you go to the schedule page, you will see the required chapters to read.
If you want to delve deeper, there are three OS books that I recommend: Operating System Concepts (the "dinosaur book"), Modern Operating Systems (the "circus book"), or Operating Systems: Principles and Practice.
Regarding books on C programming (if you want to strengthen your C) these two books are good: The C Programming Language (Kernighan) and Advanced Programming in the UNIX Environment.
In addition to the required book, I will provide cut-down* lecture notes. Please regularly visit the schedule page (under the Topic column) to download the lecture notes before you go to class.
Remember to use VPN (see Private Access section above) to download lecture notes.
* Each lecture note is not complete. The goal is for you to listen to the lecture in class and fill the missing important pieces.
To ensure you have deep understanding of how operating systems work, you will implement an x86 operating system kernel (sounds fun!). Since implementing such a kernel entirely from scratch is infeasible in a single quarter (and requires an in-depth knowledge of the x86 architecture), we will be using the Pintos instructional kernel (a minikernel). This kernel already implements most of the low-level functionality, allowing the student to concentrate on implementing higher-level operating system functionality, such as thread management, memory management, etc. while still allowing them to peek under the hood. This kernel also has the advantage of having been used in several OS courses at other universities, which means it has been thoroughly tested and documented. Pintos overall contains 26 KLOC; a real OS like Linux contains 15 millions LOC.
All of the assignments will be in C. We assume that you have enough background in C programming. To successfully complete these projects, you must understand fundamental concepts in operating system design and implementation. The class meets two times a week for lectures that provide this conceptual scaffolding. All information necessary to complete the assignments will be available from the class web page.
Project-related questions will appear in the midterm and final exam.
Student: "Professor, I still don't get an idea of what we'll be doing in the projects." That is a great question. Let's imagine this. In your current OS, you can create directories and subdirectories and put store your data in the form of files. That is convenient for you, but we cannot take this for granted -- long time ago OS architects decide that files and directories are a good way to help users manage their data. In this class, you are given Pintos. Unfortunately, Pintos does not support directories (i.e. you can only create files in the top directory, but you cannot create subdirectories, so Pintos users can only put all files in one directory). Student: "What???". Right! But don't worry, in this class you will learn about file and directory abstractions, and the goal of the project (in this case P4) is for you to add subdirectory support in Pintos and make Pintos users happy.
The projects are a fundamental part of this course (a high percentage of your grade!). Each of the project requires a significant amount of time, so do NOT procrastinate! Arguably, these projects are some of the hardest projects you ever write in your undergraduate experience. It is likely things will take longer than you expect. Do not wait until the day before the assignment is due to start. These assignments should be started pretty much when they are handed out, well before they are due.
If you don't trust what we say here, you can read previous course evaluations and read what previous students said about the projects.
Your projects will be graded on how well your implementation works. Your project will be automatically graded. We will test your program on a suite of input sets. Your grade will be based on how many of the tests your application passes. In fact, you can check by yourself how many tests you pass.
Each individual test
has a weight which can be found in the Grading and Rubric files
(e.g., for Project 2, please go to
src/tests/userprog and open the Grading
and Rubric.* files). If you pass all the tests and have
a good design document, you will get 100 points.
In the original project description (from Stanford), it says that the design document accounts for half of the grade. That is wrong. In cs230, your design document accounts for 10% of the project grade, and passing the tests accounts for 90% of the project grade.
When we grade your projects, we will run it on CSIL machines. We do not accept excuse such as ".. but it works on my Linux laptop". You must make sure that your project implementation runs on CSIL machines.
You will work in pairs.
You should find one project partner. Please use Piazza (under "Search for Teammates") to find a partner. Feel free to give information about your major, standing, or technical background. After you form a group of two, you should inform the instructor AND the TA.
You should get a partner by Wednesday in week2. If you haven't declared your project partner, we will assume you work alone. Find a project partner as early as you can. If you're too late, there is a chance that there is no partners left.
If you wish to work alone, that would be fine too. (But I warn you there is a lot of work). Please email the instructor AND the TA if you decide to work alone.
If things don't work out with your partner, you can break your partnership anytime in the middle of the quarter (but NOT within 3 days before a deadline). Let us know.
Please respect the exact time of each deadline. If it says 11:59:59pm, please submit before then. We will download your version of the code at that time. Any changes after that will be ignored.
Please be careful minutes near the deadline; sometimes your latest edits give you a worse grade than your earlier version (e.g. your committed version at 11:15pm is better). It is your responsibility to revert the final version to the best version.
Do not commit any new updates within one hour after the deadline because we might check out your code minutes after the deadline.
Projects are big and complex. Therefore it is permissible to discuss with other project groups about the project in general terms, how different routines/system calls work, high-level strategies for successful implementation, and help others debug their code and find problems.
However, you should not share your code directly with other project groups (e.g., by showing your code or scratch of your pseudo-code). Do not attempt to find solutions online or from previous years. We maintain a repository of old codes including all previous public online solutions, and we will run a very smart tool that can detect code duplication in many forms. Don't even try to challenge this tool. Discovery of any inappropriate code sharing will lead to harsh penalties for all involved parties. We want to emphasize that in the past we always catch teams that copied paste.
If you have any further questions on the gray area between what is OK and what is NOT OK, please feel free to ask.
Take precautions so as to prevent someone from copying your code without your knowledge:
ls -la and chmod to view
and modify permissions). If you mount your CS account to your
personal computer (e.g., mounting via SMB from a Mac Laptop), the
permission flags shown in your personal computer might not represent
the actual permissions. Please use the department-supported machines
to check the permissions accurately.
For more: University's standards for academic honesty and student conduct
If you need to meet the TA, please try your best to meet the TA during the TA's office hours.
We have a TA for this course. The role of the TA is to help you with your projects. Remember that a TA has a maximum bandwidth; if you start your project too late and you ask questions near the deadline, then it's possible that the TA won't be able to help you due to the high number of requests the TA needs to help. So always start the project early, so you can ask for help early.
The TA also has an office almost every day. So please make use of the TA's availability. If you cannot come during TA office hours (i.e. really conflicts with your other schedule) or his office hours were always full, then you can email the TA requesting a meeting time outside the normal office hours. If the TA does not respond to your email in 24 hours, please let the instructor know.
Since cs230 is not an introductory class, we expect your maturity in asking project-related questions. We cannot accept questions such as "I don't know where to start". We expect you to try everything first by yourself. If you have tried debugging a problem for hours and you feel you are stuck, then that is a good point where you can ask help from the TA. When asking questions, you need to prepare the details (e.g., "I tried this and that (be specific), but it does not work."). This way you are helping the TA to solve your problem faster.
IMPORTANT NOTE: For efficiency of troubleshooting time with the TA, before you meet the TA, we strongly suggest you to create a subdirectory in your svn (e.g. p1-doesNotWork) that reflects the code that does not work. This way, the TA can easily checkout your non-working code and debug the problem in his/her own machine. You and the TA then can try out different fixes on this non-working version.
All technical questions about the projects should be directed to the TA.
First, you should read the Pintos
Introduction. In that section, you are told to run make
and make check.
To be able to run these commands successfully on the CS Linux machines, you should follow this instruction: p1/guide-running-pintos.txt.
In the beginning of the course, please download the Pintos source code to your own directory. After you find your project partner, we will create an SVN repository for your group.
Pintos has been tested to run without issues on an x86 machine running Linux OS such as the Linux machines maintained by the CS department.