Course Info
Overview
The purpose of this course is to teach the design of operating systems and operating systems concepts that appear in other computer systems. Topics we will cover include concepts of operating systems, systems programming, networked and distributed systems, and storage systems, including multiple-program systems (processes, interprocess communication, and synchronization), memory allocation (segmentation, paging), resource allocation and scheduling, file systems, basic networking (sockets, layering, APIs, reliability), transactions, security, and privacy.
Prerequisites
CS 61A, CS 61B, CS 61C, and CS 70. This means that you understand:
- Data structures: arrays, linked lists, binary trees, and hashing
- Assembly language programming
- The C programming language
- Debugging C using GDB
- CPU caches and memory hierarchy
- Virtual memory as covered in CS 61C
- CPU pipelines and basic digital logic design
- Basic knowledge of random variables and probability distributions as covered in CS 70
If you feel that you would benefit from additional review of these prerequisites, we recommend using the following resources:
1. For a good review of probability as you’ll need it in this class, read
through CS 70 Lecture Notes
15,
16,
17,
18,
and
19.
2. Hennessy, John L. and Patterson, David A. Computer Architecture:
A Quantitative Approach. 5th edition.
Although the main content of this book goes far more in-depth into
computer architecture than you are expected to know for this class, the
appendices provide an excellent overview of some of the prerequisites.
Focus specifically on the sections below:
- 2.1 and B.1 - B.4 (you can skip the sixth optimization in B.3) review caching, virtual memory, and memory hierarchies.
- C.1 - C.2 review CPU pipelines at the level of CS 61C.
Enrollment
All decisions concerning appeals for enrolling in the course are made by CS departmental staff; the course staff have no say in the matter. If you have questions or concerns, feel free to contact the departmental staff.
If you are finishing an incomplete this term, do NOT enroll in the course. Instead, please email the instructors and head TA to coordinate your plan for finishing the incomplete. Similarly, if you are given the grade of I (incomplete) this term, you should not re-register in CS 162 in a future term to complete the incomplete, and you should instead coordinate with the instructor and head TA in a future term in order to finish your incomplete.
Additionally, if you are finishing an incomplete this term, you cannot change any grades that you had in the gradebook in the semester you were given the incomplete.
Grading
At the end of the term, each student is assigned a score out of 100 points. It is determined as follows:
- 36% Exams
- 36% Projects
- 18% Homeworks
- 10% Participation
Once students' raw scores are computed as described above, final grades are assigned using a curved scale.
Lecture & Section
Lecture attendance this semester is not required. Most lectures will be pre-recorded lectures from the Spring 2021 iteration of CS 162, and posted on the class website for you to watch. You are expected to watch these lectures online prior to the scheduled lecture time, and you can attend the Lecture Q&A hosted during lecture time (MTuWTr 3:30-5 PM PT) to ask questions about lectures that you have watched.
For example, a lecture scheduled for Tuesday (6/22) will be released online as a recording at 5pm PT on Monday (6/21). You will have between 5pm PT on Monday (6/21) and 3:30pm PT on Tuesday (6/22) to view the lecture recording. From 3:30-5pm PT on Tuesday (6/22), you can attend the Lecture Q&A and ask any questions you may have.
There will be a select few lectures that are hosted live (not pre-recorded). Such lectures will be clearly indicated on the website. For these lectures, you can come to class, and the Summer 2021 instructors will lecture on Zoom. These lectures will also be recorded and posted online if you cannot make them.
In the Summer semester, the course moves very fast, so it is imperative that you keep up with the lecture material in the course. As a result, we will have weekly quizzes in Friday discussion sections on the course material from the lectures on Monday - Thursday, starting the second week of classes. These quizzes will be short (5 questions long in 5 minutes), and if you score an 80% or higher, we will round your score up to 100%, which gives you leeway for making a small mistake. These quizzes are not intended to be difficult or stressful. The idea is that if you earnestly watch lectures on time, you will get a full score on these quizzes.
Because TAs have sections at different times, we will be making separate or randomized quizzes so that students in later sections do not have an unfair advantage. Even though students will get different questions, we will ensure that the difficulty of all the quizzes are roughly the same; regardless of which version of the quiz you get, if you watch lecture, you should be able to get a full score.
Readings
We are using the textbook, “Operating Systems: Principles and Practice” by Anderson and Dahlin (A&D). The reading from this textbook is required. There will be some additional readings that are not from this textbook that are freely available online. These will be linked on the course website in the "Readings" column for your viewing.
Required
Operating Systems: Principles and Practice (2nd Edition)
Recommended
Operating Systems: Three Easy Pieces
Supplemental
Linux Kernel Development (3rd Edition)
Participation
Your participation score will be broken down into the following categories:
- 35% Design Review Participation
- 20% Discussion Attendance
- 15% Discussion Participation
- 20% Weekly Lecture Quizzes
- 10% Mandatory Surveys
It is important that you attend discussion sections and design reviews and get to know your TA. These will provide essential specifics on hands-on aspects of the course, including tools, techniques and concepts. In the past, TAs have bumped borderline grade cases up or down based on participation.
Design review attendance and participation is mandatory with cameras ON, and excusals will only be granted in extreme circumstances. An unexused absence from design review may result in a zero for both the design review participation score and/or a penalty on the design document & project score itself.
Discussion attendance is also mandatory, with cameras ON. If you have a legitimate reason to miss section, please notify your TA beforehand and your absence may be excused. If you have too many unexused absences, you will lose points.
Weekly lectures quizzes will be given in discussion. See the "Lecture & Section" section for more details. If you have an excused discussion absence, your TA will work with you to make up the lecture quiz.
Please also complete all mandatory surveys. Survey links will be released on on Piazza and appear on the course website. These are free points, and really help us improve the course!
Exams
There will be one midterm exam and one final exam in the course. Each exam will be cumulative and cover material seen in the course so far. Please consult the class schedule for the dates and times of these exams. If you have a conflict, let us know, and we will schedule a make-up exam. Exams will cover material from lecture, sections, the readings, homework assignments, and projects. You are likely to do poorly on the exams if you do not do your share of work on the project.
Exams will be delivered in a remote format, and will be live proctored using Zoom. The official proctoring policy and technology requirements will be released on Piazza closer to exam time. Please contact the course email if you have any questions or concerns.
Our exams will be closed-book. You may be allowed some number of handwritten cheat sheets, which we will specify prior to each exam. You are allowed to write these on a tablet and print them out. You may not collaborate with other people, either in person or online, during the exams.
Clobber Policy
To further alleviate stress and exam pressure this term, we are instituting the following clobber policy. By default, the weight of each exam is:
- 16% Midterm
- 20% Final
- 12% Midterm
- 24% Final
Homeworks
The homeworks and projects in this class are a great way to get hands-on experience building systems. We have tried hard to keep the workload manageable and to focus on learning concepts, rather than busy work.
Homeworks and projects will all be submitted and autograded via GitHub. Individuals and groups will have course-provided GitHub repositories. Intermediate pushes will help the staff see how students are progressing.
We see homework mostly as a chance for exercise. Solutions will not be made available online, but you may come to Office Hours to see them 2 days after all possible slip days on the assignment have expired.
Projects
We will be using the Pintos educational operating system for all four projects this term. The projects in this course provide a deep experience with operating system and distributed system design and implementation. The project experience is essential to the course.
If you plan to do software or hardware development after graduation, you will almost certainly need to know how to work in a group. Recent CS grads almost all say that the ability to work in groups was the single most important thing they wished they had learned at Berkeley. Hence, for these projects, you will need to form into groups of 4 people. We will not permit anyone to do the projects in a group smaller than 3, and we will only permit a few groups to have a size of three, if the class is not evenly divisible by 4.. The assignments will be the same no matter what size group you have. In order to ensure everyone in the group does their fair share of the work, we will ask each of you to turn in assessments of the relative contributions of your project partners. These assessments are important, and they can have a substantial impact on your grade if you do not participate.
TAs will grade all parts of your project. The TAs have been instructed to grade in part on design. In other words, it is not enough to get a working solution; you must implement the solution in a clean way that would simplify making further enhancements. (Several employers in the area have said that many of our graduates don’t know how to program well — it will really benefit you in the long run to work on your software engineering skills.)
For each project, you will turn in an initial design document and a TA will meet with your group for an oral presentation of your design at a design review. These reviews serve several purposes:
- To encourage you to get an early start on the assignments (a key to success in this course).
- To catch design errors early, before you spend a lot of time debugging.
- To give you an opportunity to explain and defend your approach (this is an important skill to learn as engineers).
- To provide an opportunity to assess your understanding of the project.
Late Policy
All assignments are due at 11:59:59 PM Pacific Time on the day listed on the schedule.
Your group gets 3 project “slip days”. Project slip days can not be used for Project 0 or design docs submissions. After the project slip days are used up, you will no longer be able to submit the project and your autograder score will not change.
There are 2 homework “slip days”. Homework slip days can not be used for HW0. Project 0 will use homework slip days instead of project slip days, since it is an individual assignment. After the homework slip days are used up, you will no longer be able to submit a homework late and your score on the late homework will not change.
Slip days can only be used in whole numbers. Although no credit will be given for submissions after slip days have expired, we may be lenient in special circumstances, and grant manual extensions on assignments at our discretion. Please stay in touch with your TA and keep them updated on any circumstances that may lead you to submit a homework or project late.
Piazza Policy
Piazza will be the main mode of communication this term. Please make sure to check it regularly! Please also be sure to abide by our Piazza Etiquette Policy when interacting with students and staff on Piazza.
OH Policy
TAs will host office hours throughout the week. In order to get help from a TA on course content or homework/project debugging, please join the OH Queue.
When submitting a ticket on the OH queue, you must use the provided ticket template. If students don't have a templated ticket, the ticket may be ignored and you will not receive help until the formatting has been fixed. Please also make sure to abide by all our OH Policies outlined on Piazza.
In addition to Lecture Q&A sessions during normal lecture times, the instructors will also host all-day conceptual OH on Fridays by appointment! Please see the OH calendar on the main page of the website for information on how to sign up for a slot.
Collaboration Policy
Note: Projects are a shared responsiblity and all project members will incur penalties for cheating. You are accountable for the actions of your teammates.Maintaining academic integrity is a crucial part of your learning experience, as cheating prevents us as instructors from understanding where our model of instruction isn’t working. We encourage you to ask other students in this semester’s course about the concepts, algorithms, or approaches needed to do the projects and assignments; both giving and taking advice will help you to learn. However, what you turn in must be your own, or for projects, your group’s own work; copying other people’s code, solution sets, or from any other sources, including online sources, is strictly prohibited. The project assignments must be the work of the students turning them in. Wherever you have benefited from the work of others, you should credit it properly in your code and/or writeup. Note: Only projects are group assignments. Homeworks are individual and you should not look at or copy other code, even that of your project groupmates.
Examples of acceptable collaboration between students in different project groups in this semester’s course:
- Explaining a concept to another student, or asking another student to explain a concept to you
- Discussing various algorithms or approaches for project components
- Discussing testing strategies and approaches
- Searching online for algorithms or implementations of generic (non-project-specific) abstractions (e.g., searching for various implementations of a hash table)
- Helping another student with high-level debugging approaches (note that it is not acceptable to give that student code solutions or even look at their code, as described below)
Examples of unacceptable collaboration:
- Looking at code from a different group’s project or another student’s homework — this includes looking at online code from prior semesters or other institutions
- Using code from a different group’s project or another student’s homework — this includes incorporating online code from prior semesters or other institutions
- Looking at or using specific test case instances from a different group’s project or another student’s homework — this includes incorporating online code from prior semesters or other institutions
- Searching online for specific implementations of project abstractions or functions
We use an automated system for detecting cheating: it performs a pairwise comparison of all assignment submissions with all others for this class, prior semester classes, and various online repositories. The system reports any suspicious similarities. The course staff will manually review any such similarities. Moreover, we have a dedicated staff of readers who will manually review code, and note similarities between algorithms and designs used in other students solutions as well as any solutions available online. Do NOT try to fool our automatic cheating detection system, because you WILL be caught by our human readers.
Note that you are responsible for not leaving copies of your assignments lying around and for protecting your files — do not use public unprotected source code repositories to store your code. You must set up your files and directories so that they are protected from others reading them.
Any mechanisms used in attempt to "hardcode" solutions to homeworks or projects will be punishable as cheating cases. We reserve the right to evaluate submitted code on our private test suites which can detect hardcoded solutions, and our readers may manually inspect your code solution for any such instances of cheating.
If two assignments are determined to be obviously very similar (i.e., we believe that they were done together or one was copied from the other), then all the students involved the incident, both the copy-er and the copy-ee, will receive a penalty. The minimum penalty is to receive a negative score on the assignment. More serious cases of academic dishonesty, such as repeat offences or cheating on exams, will incur a greater penalty at the instructor's discretion, such as receiving an F in the class. In addition, for every instance, a letter to the Center of Student Conduct will be attached to your permanent record, and a copy will be placed in the CS division office.
This course is challenging. If you ever feel tempted to resort to academic dishonesty to meet a deadline, please don't. Contact your TA instead, they are here to help!
Course Material Policy
Under no circumstances are students permitted to upload course materials online or distribute these materials to anyone enrolled or not enrolled in the course. This policy will be enforced during and after the course.
This policy applies to any course materials that are not already publicly available, including but not limited to:
- Exam Questions and Solutions
- Design Documents and Final Reports
- Homework and Project Solutions
Please see the Collaboration Policy for information on sharing course materials among enrolled students.