Discussion forum: http://piazza.com (signup)
Staff e-mail:
Introduction to Operating Systems
EECS 482 (Winter 2018)
Web page: http://web.eecs.umich.edu/~harshavm/eecs482
Discussion forum: http://piazza.com
(signup)
Staff e-mail:
EECS 482 is an introductory course on operating systems at the senior undergraduate or first-year graduate level. The objective of the course is to teach the issues involved in the design and implementation of modern operating systems. The concepts in this course are applicable to many operating systems and hardware platforms. We will discuss examples that are drawn from historically significant and modern operating systems including MULTICS, UNIX, Mach, and Windows. We will cover topics such as processes and threads, concurrency and synchronization, CPU scheduling, virtual memory management, communication in distributed systems, secondary-storage management, and file systems.
To help you understand operating systems, you will implement several modules that form much of the core functionality in modern operating systems. These projects will give you practical exposure to topics such as threads, virtual memory management, client-server systems, and file systems. We will also assign homework questions that will be covered in the lab sections.
Students must have completed EECS 281 and EECS 370. Students should understand data structures and computer architecture, have extensive C/C++ programming experience, and be familiar with UNIX.
The recommended textbook for the course is Operating Systems: Principles and Practice (2nd edition), by Thomas Anderson and Michael Dahlin (ISBN 0985673524). There will also be lecture notes and supplementary readings posted on the course web page. Course announcements and project help will be posted on the discussion forum.
Four projects will be assigned during the semester. Each project will require a substantial time commitment on your part.
Three of the four projects in this course will be done in groups of 2-3 students (Project 1 is done individually). Groups may be drawn from the entire EECS 482 population; members of a group need not all be in the same lecture or lab section. Declare your group's membership by January 22, 2018. After this date, we will form groups from the remaining students. Choose your group members carefully. You should discuss topics such as prior experience, course background, goals for this course, workload and schedule for this semester, and preferred project management and work style. Make sure you can find several blocks of time during the week to meet to discuss or carry out the project. Students who have worked on any EECS 482 project in a past semester should talk with an instructor before joining a group.
Students are expected to work diligently in their group for the benefit of the entire group. All group members should be familiar with all aspects of each project, irrespective of their role on the project. We expect all group members to contribute their fair share, and we expect to assign the same project grade to all members of a group. To help ensure this, group members will evaluate the contributions of other group members after each project. Members who contribute less than their share may receive a lower grade on the project; non-contributing members will receive a zero. In case of disputes regarding contribution, an instructor may examine the commit log or interview group members.
Students may be fired from a group by the majority vote of the remaining
members. The procedure for this is as follows: (1) documented "gentle
warning" of risk of firing in e-mail, with cc to all group members and to
, with cause and specific work
required to remain in group; (2) allow at least 72 hours for compliance;
(3) if the problems persist, e-mail statement of firing to the group and to
. Fired group members may join
another group; students who cannot find a group must complete the remaining
projects by themselves.
Managing group dynamics and using each group member's time and talents effectively can be difficult. If there are problems with your group, please see an instructor as soon as possible. Be open and candid with your group about potential problems early on so your group can plan around those problems and not fall behind. A sure way to make your group upset at you is not finishing your work at an agreed-upon deadline and not informing them about the problems early enough for them to help. We encourage everyone to read Coping with hitchhikers and couch potatoes on teams.
All projects will be hosted at github. Please sign up for a free github account if you don't already have one, then register your github username with us. The eecs482 organization at github will provide a private repository for each group for each project. Commits to the repository should reflect the proportion of work performed by each group memer. If you use pair programming, take turns at the keyboard so that the commit log reflects the contributions of both members.
Sometimes unexpected events make it difficult to submit a project on time. For this reason, each group will have a total of 3 late days to be used for projects throughout the semester. These late days should only be used to deal with unexpected problems such as illness. They should not be used simply to start later on a project or because you are having difficulty completing the project. Once late days are used up, submissions received after the due date will not count (even if they are just one second late). Try to save some late days for the last project. Weekend days are counted in the same way as weekdays (e.g., if the project deadline is Friday and you turn it in Sunday, that's two days late).
To request an extension beyond the free late days, you must discuss your situation with an instructor before the deadline and provide written documentation. Extensions will typically not be granted, even for computer problems, illness, family emergencies, etc.. In most cases, with cooperation and good faith on your part, your group will be able and expected to make up the deficit without needing an extension. You can avoid most problems by starting the projects early and keeping backup files. If a family/personal emergency causes you to miss a significant number of days, please see an instructor to decide the best course of action. If you are having trouble understanding the material or starting a project, please come to office hours for help right away.
Contact an instructor at the beginning of the semester if you have a disability that might interfere with your ability to participate in class, submit assignments, or take exams.
All projects in this course are to be done by your own group and in accordance with the College of Engineering Honor Code. Violation will result in a zero on the project in question and initiation of the formal procedures of the Engineering Honor Council.
At the same time, we encourage students to help each other learn the course material. As in most courses, there is a boundary separating these two situations. You may give or receive help on concepts covered in lecture or lab and on the specifics of C++ syntax. You may consult with other students to help you understand the project specification (i.e., the problem definition). However, you may not collaborate in any way when constructing your solution--the solution to the project must be generated by your group working alone. Any misrepresentation of another person's work as your own is unacceptable and is a violation of the honor code. You are not allowed to work out the programming details of the problems with anyone or to collaborate to the extent that your programs are identifiably similar. You are not allowed to look at or in any way derive advantage from solutions or code that you did not write. If you worked on the projects in the past (e.g., if you are repeating EECS 482), you are not allowed to re-use code that your group wrote from the prior semester.
If you have any questions as to what constitutes unacceptable collaboration, please talk with an instructor. You are expected to take reasonable precautions to protect your work. You may not post your work in a publically accessible location, such as public code repositories. Don't let other students borrow your account or computer; don't leave your program in a publicly accessible directory; and don't discard printouts in a public place.
The most common reason for doing poorly on the projects is starting them late. You will be given plenty of time to complete each project. However, if you wait until the last minute to start, you may not be able to finish. Start early, and plan to have it finished a few days ahead of the due date. Expect to spend more time debugging the code than you did writing it.
The most common reason for spending too much time on a project is coding before thinking through the entire project. Resist the urge to start writing code as your first step; you are likely to code yourself into a corner. Meet with your group and plan out the architecture of your solution. Expect to revise this architecture several times before settling on a plan. Read the project description carefully, and list the behaviors the specifications require of your solution. The more you think through and understand what needs to be programmed before you write code, the better. Design your project with independently and incrementally testable subsystems rather than saving all testing for the end. Assign one project member as the Testing Czar; that member's job is to see how he or she can break the group's solution with the simplest possible test. Another common reason for spending too much time on a project is debugging by trying things at random, just to see if they work. If you find a workaround without understanding why it fixes the problem, you may be masking the problem rather than fixing it, and it will probably cause more problems later and be harder to fix. If you find yourself in this position, step away from the computer and think about what is happening, or come see an instructor in office hours.
There are many sources of help on which you can draw. Most questions can be submitted to the teaching staff and your fellow classmates via the discussion forum. These will typically be answered within the day, often more quickly during working hours. However, some types of questions cannot be answered without seeing your project. If you have detailed questions about your program, speak to an instructor during office hours. Students are also encouraged to help one another on the course concepts (but not the implementation of the projects). One of the best ways for you to make sure that you understand a concept is to explain it to someone else. Keep in mind, however, that you should not expect anyone else to do any part of your project for you. The project that you turn in must be your own.
Many computing sites have consultants who are available to help you. They can often help with questions about the computers, printers, and installed software (e.g., Unix, AFS, e-mail). However, they probably will not be able to help you with questions about operating systems, C++, or specific errors in your program.
There will be two exams during the semester: a midterm exam (6:30-8:30 pm on Feb 20) and the final exam (7-9 pm on Apr 23). You are expected to take both exams at the scheduled times.
If you miss an exam for reasons other than a documented medical or personal emergency, you will receive a zero for that exam. If you anticipate a conflict with an exam time, talk to the instructor at least one month before the exam date. Exam dates are given at the beginning of the semester so you can avoid scheduling job interviews or other commitments on those days. Outside commitments are not considered a valid reason for missing an exam.
You are expected to attend lecture regularly and to be at your lab section weekly. Lab sections will typically involve active participation via group and individual exercises, question-and-answer sessions, or discussions.
Final grades will be based on the total points earned on the projects and exams. You must average a passing grade on the exams to receive a passing grade for the class. Factors such as class participation may be used to adjust your final grade, especially if it falls on a borderline. The tentative point breakdown is:
Project 1: 3%
Project 2: 15%
Project 3: 15%
Project 4: 15%
Midterm exam: 26%
Final exam: 26%
You may use any x86-64 PC that runs RHEL Linux 7 and g++ (version 4.8.5). We recommend you use the computers in the CAEN labs or Duderstadt Center, either directly or by logging in from another computer.