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.