CSE 451, Introduction to Operating Systems, Fall 2017
Course OverviewDiscussion board
This iteration of the course will use Piazza for project and course questions. You should have already received an invitation; if not, please email Michael or Johan.
The text for the course is Operating Systems: Principle and Practice, Anderson and Dahlin, second edition (the one with Mt. Rainier on the cover).
Readings assigned for each lecture are listed on the course calendar. Lecture topics, exams, homework and project due dates can all also be found on the calendar. Note that you can subscribe to the calendar - this is very convenient.
- Labs: 75%
- Final: 25%
There will be a comprehensive final exam for this course; however, most of the grade is the project and that should be your primary focus.
Because of the tight timeline for the labs, we do not plan to hand out problem sets this quarter.
The core of the course is a new project, xk. To get the project, please run:
git clone firstname.lastname@example.org:xk-public/au17.git
And then follow the instructions in lab 1.
The baseline code for xk is a very primitive working operating system (e.g., it can run a single small program). xk could boot on real hardware, but to simplify debugging we will run it on a simulated virtual machine. The labs ask you to add some system calls, make the operating system capable of running multiple processes, add a relatively full-featured virtual memory system, and add transactional updates to the the file system.
The project is to be done in groups of 2 people; you will get the most out of the project if you do pair programming. Every quarter, a few students ask us if they can do the project individually. We will encourage you to find a compatible partner, but as the labs will be mostly auto-graded, we plan to allow individual solution sets. (Note that the assignments get progressively more difficult so please keep that in mind.)
Each project assignment involves answering a set of questions about the assignment; these will be graded. In addition, we expect students to submit a written description of the design of their solution; we grade these independently of our tests of the implementation. Thus, partial credit can be received for answering the assignment questions and understanding how to do the assignment, even if your code does not completely work.
We grant each group seven slip days for the project assignments, for you to use at your discretion. These are calendar days -- weekends and holidays count. Regardless of your remaining slip days, all assignments must be turned in by midnight on Sunday, December 10. In other words, no slip days are available for use on the last assignment.
If you find yourself falling behind in the project, please do not panic, but please do contact the instructor. We would like you to do the labs in the order we have assigned them, even if it means using up your slip days or going beyond that. You may freely drop the last assignment for a 0.5 grade point deduction (and the last two for 1.0 deduction, and so forth). In that case the rest of your assignment due dates will be shifted back by one (or more) slots.
CSE's Academic Misconduct Policy.
Collaboration is a good thing. On the other hand, cheating is a serious offense. Please don't do it! Concern about cheating creates an unpleasant environment for everyone. If you cheat, you risk losing your position as a student in the department and the college. The university policy has recently changed to require faculty to report all cases to the college cheating committee.
So, how do you draw the line between collaboration and cheating? A great one-sentence guideline is highlighted in our Academic Misconduct Policy:
"In general, any activity you engage in for the purpose of earning credit while avoiding learning, or to help others do so, is likely to be an act of Academic Misconduct."
For this quarter, I will have very relaxed rules with respect to collaboration on the project. You are encouraged to ask for help, from the instructor, from the TA's, from other students. However, do not cross this line: On the project, do not share code or text. Do not consult project solutions that might be on the Internet. Do not use someone else's code or text in your solutions. Sharing ideas, explaining your code to someone to see if they know why it doesn't work, even helping someone else debug if they've run into a wall, all that is ok.