University of Mary Washington
Department of Computer Science
CPSC405: Introduction to Operating Systems
TTh 6-7:15pm Trinkle B6
I really like Professor Dahlin’s description of his operating systems course:
The crosscutting theme in this course is providing abstractions above imperfect hardware to make it usable by programmers and users. At the end of the course, students should understand a set of abstractions (concurrent programming, virtual addressing, memory protection, caching, transactions, …) that are useful in many large-scale software systems not just OS kernels. More important than memorizing specific abstractions used in operating systems of the past, students should understand these abstractions well enough to synthesize their own abstractions when faced with new problems.Another important goal of the course is for students to understand the computers they use and on which they build their applications. A student graduating with a CS degree should believe “there is no magic”: they should be able to describe the chain of events that occurs when they hit a key and cause a letter to appear on the screen from the register level (or logical gate level or transistor level) to the system architecture level to the operating system level to the application level. This is philosophically important, but it is also of practical interest to developers who need to figure out how to make a system do what they want it to do.
- to develop the ability to read (and apply) program specifications and technical documentation.
- to develop the ability to meet coding deadlines
- to acquire a good understanding of the structure of operating systems including
- process synchronization
- memory management
- virtual memory
- file-system interface and other I/O
- gain basic core competencies in kernel development. This includes extending a barebones kernel to include executing user processes, paging, and file management.
- develop abilities to critically compare operating systems and assess emerging technologies.
This is a programming intensive course.
This semester we will be working through a series of projects developed at MIT and used for a number of courses including the honors introduction to operating systems course at the University of Texas at Austin and the operating system engineering course at MIT, as well as courses at Stanford and UCLA. Professor Frans Kaashoek has given us permission to use this material. I will follow Professor Dahlin’s pair programming approach to these labs. He describes it this way:
You will work on this project in teams of two. You are responsible for forming a team with someone with whom you will work well, and resolving any problems that arise during the partnership is your responsibility. If you are unable to resolve a serious problem, the instructor will arbitrate.
Your team must follow a pair programming methodology. In particular, both members of the team must work together to understand the problem, design your solution, enter code, and test your solution. For code entry, one member should type while the other observes, detects tactical coding defects, and thinks strategically about the overall design. These roles must be frequently swapped. You might also want to consider the XP strategy of designing your tests before you design your solutions. In general, studies suggest that pair programming works well: (1) counter-intuitively two programmers working together at one keyboard produce about as much functionality as two programmers working apart at two keyboards, (2) the code produced in this manner is of higher quality than individually programmed code, and (3) in an educational setting both team members learn more than they would separately. Note that for this project, these advantages of pair programming over disjoint work are especially likely to apply: it is vital that both team members understand all aspects of the implementation. Also be aware that the exams will have questions that required intimate knowledge of the project.
This project will be challenging. The programming labs are time intensive and you should plan your class schedule accordingly.
Projects can be developed on lab computers (Rosemary) or your own computer. For complete instructions on how to develop on your own machine see the write-up to lab 1. Projects will be graded based on how they run on the lab computer environment. Be sure to test your code on a lab computer before submitting it.
Projects are due anytime on the due date. That is, if the due date is on a Saturday, you can submit the project up to midnight Sunday. Projects turned in by 8am the following day will likely incur a 7% penalty. Projects turned in between 8am the following day and midnight will likely receive a 15% penalty. Students unable to complete a project due to illness or family emergency should contact me as soon as possible.
The lab you submit must be your team’s own work. There will be opportunity in class to discuss the projects in a general way with students in your group, but you may not examine any other team’s code. Sharing code on programming assignments is a form of academic dishonesty. Significant similarity of notation or form between submissions of different students or between a student’s work and solutions found on the web will be regarded as evidence of academic dishonesty. Also, you also should not google and find lab solutions for any similar course.
Any team can appeal a project’s due date. The appeal must be supported by every member of the team and must be verbally presented at the beginning of a class period. The appeal must include 1) the source of why the project cannot be completed by the original due date, 2) offer an alternative due date, and 3) specify evidence that the proposed due date is reasonable. If an appeal is granted the new due date will be for the entire class. I also may extend due dates on my own.
As I mentioned, this is a programming intensive course, and I expect students to make a good-faith effort to complete the programming assignments.
During the first day of class, all students will be assigned to permanent teams. Throughout the course, teams will both take team tests and participate in joint activities. Team performance will be one component of your final grade.
If you have had me for another class you are familiar with my grading scheme where the class decides on how the final grade is determined. This semester I am trying out a new scheme. Grading is based on a method developed by Professor Lee Sheldon at Indiana University. It is based on obtaining experience points (XP). The number of XP determines what level you are at. You start the class at Level 1 and with 0 XP. The level you obtain at the end of the semester determines your final grade. Here is the chart:
I differ from Professor Sheldon in offering students options on how to accumulate XP. There will be opportunities to earn at least 2350XP during the course. This gives each individual some flexibility in what tasks to do. You gain XP working individually, with a partner, and with your team.
Programming Projects – 700XP
There will be approximately 4-5 programming projects involving Intel assembly and C. The projects will be identical or nearly identical to the ones in last year’s class. Each project will be worth between 150 and 250XP.
Quizzes – 400XP
There will be approximately 5 short multiple-choice quizzes given during the course. Each quiz will be taken individually, then, immediately after, the same test will be taken as a team. Each individual quiz is worth on average 30 points; each team quiz is also worth on average 30XP. You will have advance notice of these quizzes.
Team Work (in-class) – 500XP each team member
There will be a variety of activities worth between 50-75XP. The vast majority of team work will be done during class time. However, to get maximum points on a particular task you may need to meet occasionally outside of class.
Team Reading Presentation – 75XP each team member
Teams will do a presentation on a section of the textbook or an assigned reading.
Partner Reading Presentation – 150XP
You will do a presentation on a section of the textbook or an assigned reading.
Individual HW – 150XP
These can be either short programming problems or questions.
Team Participation – about 120XP
Each student will rate the helpfulness of all members of their team. Individual team participation scores will be the sum of the points they receive from other members of their team. Each team member distributes 100 points to other members of the team. The average team participation score will be 100 points. The rater must differentiate some of their ratings (they cannot assign the same rating to all members).
Exam – 250XP
Throughout the semester I will post questions & problems. These are part of the final exam for the course. You can elect to complete the work anytime between the time the problem is posted and the Thursday Dec. 9th at 9:30pm. You will gain 10% more XP if you complete the work within a week of the problem being posted.
Avatar names, pseudonyms, noms de plume
During the first week of class I will ask you for your avatar name, pseudonym, whatever. This is the name that will appear on the Experience Point Google Spreadsheet that will be viewable by everyone in the class. If you wish to remain anonymous, don’t share your avatar name with anyone. On the other hand, if you would like recognition for achieving level 10 as an example (“a big shout out to tera miner for achieving level 10”), you can share your name. The decision is yours. To further protect the anonymity of those who wish to remain anonymous, the spreadsheet will also be populated by fictitious avatar names.
Accommodations for students with special needs
Any student with a documented disability may receive a special accommodation to complete any requirements of this course. If you are have a disability or believe you have one you may wish to self-identify. You may do so by providing documentation to the Office of Disability Services located in Room 203 of George Washington Hall (Phone: Voice 540-654-1266, Fax: 540-654-1163). Appropriate accommodations may then be provided for you. If you have a condition that may affect your ability to exit the premises in an emergency or that may cause an emergency during class, you are encouraged to discuss this in confidence with me and/or anyone at the Office of Disability Services. This office can also answer any questions you have about the Americans with Disabilities Act (ADA).