Types of operating systems. Concurrent programming. Management of storage, processes, devices. Scheduling, protection. Case study. Course includes a programming laboratory.
| Term: | Fall 2022 |
| Department: | COMP |
| Course Number: | 530 |
| Section Number: | 001 |
| Time: | MW, 4:15-5:30 PM |
| Location: | SN 014 |
| Website: | http://www.cs.unc.edu/~porter/courses/comp530/f22 |
| Name: | Dr. Donald Porter |
| Office: | Fred Brooks 344 |
| Email: | porter at cs dot unc dot edu |
| Phone: | 919-590-6044 |
| Web: | http://www.cs.unc.edu/~porter |
| Office Hours: | Scheduled on Course Care, or by appointment. |
All office hours will be scheduled on Course Care, or by appointment.
| Name | |
|---|---|
| Yufei Du | yufeidu at cs dot unc dot edu |
| Tao Tao | ttao at cs dot unc dot edu |
All office hours will be scheduled on Course Care, or by appointment.
| Name | |
|---|---|
| Yang Hu | yanghu at live dot unc dot edu |
| Eric Schneider | u1643364 at live dot unc dot edu |
Required Textbook: We will be using this book for required course readings, as listed on the course schedule. The readings will not necessarily be in order, and I will supplement the book with additional required and optional resources as needed. All required readings will be placed on the course schedule.
Remzi Arpaci-Dusseau and Andrea Arpaci-Dusseau
Operating Systems: Three Easy Pieces
Free online here: http://pages.cs.wisc.edu/~remzi/OSTEP/
Most of the course materials will be on the course website. We will also use Piazza for class discussions, and Sakai only for posting assignment grades.
A number of helpful references for the labs are available on the References page.
Optional Textbooks: The following books are useful references for this course and OS kernel programming in general. These books are available from amazon, and several are available for free online via the UNC library (links below).
Other recommended operating system textbooks and references (in no way are these required purchases for the course):
Thomas Anderson and Michael Dahlin
Operating Systems: Principles and Practice, 2nd Edition
Recursive books (August 21, 2014),
ISBN: 0985673524
Marshall Kirk McKusick, George V. Neville-Neil
The Design and Implementation of the FreeBSD Operating System
Pearson Education, 2004.
ISBN: 0201702452
Uresh Vahalia
Unix Internals: The New Frontiers
Prentice Hall, 1996.
Andrew S. Tanenbaum
Modern Operating Systems
Prentice Hall, 1992.
If you need help with C or Unix, I recommend these texts:
Brian Keringhan and Dennis Ritchie
The C Programming Language (2nd ed., ANSI version)
Prentice-Hall Software Series, June 1988.
ISBN: 0131103628
Brian Keringhan and Rob Pike
The UNIX Programming Environment
Prentice-Hall Software Series, March 1984.
ISBN: 013937681X
Æleen Frisch
Essential System Administration, 3rd Edition
O'Reilly & Associates, August 2002.
ISBN: 978-0-596-00343-2
Ellen Siever, Stephen Figgins, Robert Love, and Arnold Robbins
Linux in a Nutshell, 6th Edition
O'Reilly & Associates, September 2009.
ISBN: 978-0-596-15448-6
If you are interested in more detail on Linux kernel programming, I recommend these references:
Daniel P. Bovet & Marco Cesati
Understanding the Linux Kernel (3rd edition)
O'Reilly & Associates, Novemeber 2005.
ISBN: 0596005652
Note: Be sure NOT to get the older editions of this book, which covered
Linux 2.2 (1st ed.) and 2.4 (2nd ed.).
Jonathan Corbet; Alessandro Rubini; Greg Kroah-Hartman
Linux Device Drivers (3rd edition)
O'Reilly & Associates, February 2005.
ISBN-13: 978-0-596-00590-0
This book is has a more accessible introduction to compiling your own kernel and writing your own module than Bovet and Cesati,
as it is intended to be a practical guide to writing device drivers.
Robert Love
Linux Kernel Development (3nd Edition)
Addison-Wesley Professional, 2010.
ISBN: 0672329468
Christian Benvenuti
Understanding Linux Network Internals-->Understanding Linux Network Internals
O'Reilly Media; 1 edition (December 1, 2005)
ISBN: 0596002556
An operating system is an essential part of almost all computer systems. In fact, your cell phone, your car, and most consumer appliances that contain a processor have an operating system inside. Your car probably has at least 10 different operating systems lying about.
At a high-level, the principles of operating systems include topics such as how to securely and fairly share resources among multiple applications; how to design abstractions for hardware resources that balance ease of programming with expressive power; and techniques for coordinating concurrent access to a resource.
More specifically, this course will primarily study general purpose, time-shared operating systems. In this context the operating system is the software system that provides the interface between users, their applications, and the underlying hardware. The purpose of this course is to introduce some of the fundamental concepts in the design of a time-shared operating system. These include:
More philosophically, a computer scientist with an bachelor's degree should not view any part of the computer as "magic," but should either understand how it works or have the tools to figure it out. For instance, when one types a command at the console, what is the chain of hardware and software events that lead to the command returning the correct value?
Thus, an important part of the course will be the hands-on experience. For that, you will developing assignments on a Linux system. Some assignments will require low-level user-level programming.
The course is geared towards advanced undergraduate computer science majors and first year graduate students in computer science. Operating systems is a classic topic in a computer science curriculum as the problems of resource allocation, management of concurrency, and file storage have always been present in some form in nearly all computing environments. You can't understand how a computer operates until you understand what an operating system is, how it functions, and how it is organized.
The prerequisites for this class are:
If you've taken equivalent courses elsewhere, and they include actual programming experience in C/Unix, please speak to me first to get an approval to take this class. If you've never taken an introductory C/C++ course before, you may not take this class; in some cases, having industry experience in the same field is enough.
C Programming: You should already know the basics of programming and debugging in C programming language.
This course will be taught in C, and you will complete substantial,
user-level programming assignments in C. We expect that a typical student
will become much more proficient in C over the course of the
semester. However, because this is not a C course, the time spent in
class on C will be minimal.
If you do not know C and would like to take the course, I would recommend
reading "The C Programming Language" by Kernighan and Ritchie and working
the exercises in the book BEFORE THE FIRST DAY OF CLASS.
A dedicated student that is proficient in another language (e.g., Java)
can probably accomplish this in a week or two.
You should already have basic exposure to Unix commands and the command line. You should know what commands such as ssh, gcc, make, man, ls, mkdir, vi/emacs, and gdb do, or be able to figure this out on your own (via google and friends). In general, we will not teach you how to use Unix (we'd like to spend the time teaching you about operating systems instead), although we may discuss particularly tricky commands.
If you do not fulfill the above requirements, you should very strongly consider postponing COMP 530 until you are more prepared.
Students will learn how to write concurrent programs, how to synchronize concurrently executing processes, and how to communicate data between such processes. They will learn how to allocate system resources such as memory and processor cycles to processes and how such allocation decisions affect system performance. They will also learn how system resources can be virtualized and shared between processes so as to provide the abstraction that each process is executing on a dedicated machine.
The course is taught in an interactive lecture style. Although there are slides and planned topics to discuss, students are expected to answer questions during the lecture and ask questions. Attendance is expected, but will not be recorded.
To help students review and synthesize course concepts, we will assign worksheets, to be completed in a small group outside of class. Worksheets will be "discussed" between groups using a social media site for the course. The groups will change approximately every week and in total students will complete approximately 8-10 worksheets.
Students are also expected to complete roughly 4 programming assignments. The programs will be written in the C programming language on a departmental Linux server and will each emphasize some aspect of operating system design and implementation.
Lectures will be recorded and be made available to the students in the class. These recordings are intended to help students review the material after attending lectures, and are not a substitute for attending lectures in person. Lecture attendance is still expected, to facilitate questions, announcements, and discussion. If lecture recording substantially harms attendance, it will be discontinued.
This is a best-effort service and should not replace lecture attendance. Student questions, chalkboard drawings, and other materials may not record properly. Moreover, my experience has been that a few lectures are lost each semester for unforeseen technical difficulties (e.g., the recording space fills up mid-lecture, a file gets corrupted).
There will be two in-class exams: Mon 10/3, and Weds 11/2, held during class time.
There will be a final exam at 8am on Friday, Dec 9.
Please mark your calendars now. If you have a conflict with the midterm, tell the instructor during the first two weeks of class, and we will schedule a makeup for a time before the exam is given to the rest of the class.
The final grade will be determined as follows: The raw scores obtained by all students on each assignment and exam will be standardized for that particular assignment or exam either (at my discretion) by converting them to percentile scores, or else by applying a linear transformation to map the scores to a standard [0, 100] scale. A weighted sum of the resulting standardized scores will then be formed (with weights as shown below) to obtain a composite score for each student.
Finally, the composite scores will be ranked, and I will apply a subjective method of my choice to determine the cutoffs for each grade category. Absolute performance standards, the distribution of composite scores, information derived from late homeworks, and class participation are factors likely to contribute to this decision.
In assigning final grades, I often take into account evidence of improvement over the course of a semester. However, I will not entertain end-of-term pleas to get a certain grade.
So that you can get an idea of how you are doing as the term progresses, I will report rough percentile information when I hand back each assignment. Final percentile scores will not be computed until after all grade changes and corrections have been taken into account at the end of the term.
The exams are closed book and include a mix of multiple-choice, short answer, and programming questions.
Re-grading: we will handle regrade requests on gradescope. It's highly recommended that you take some time to review your entire assignment before requesting a regrade. We reserve the right to regrade the entire assignment or exam, not just the question raised in the regrade request. Your grade can be improved or harmed by regrading.
Extra credit: Some labs may include optional challenge problems, which may be completed
for extra credit. Please indicate if you do these in your lab's challenge.txt file.
The instructor may also assign bonus work in class at my discretion.
Any extra credit points accrued by any student will be used as follows.
The final course grade will be assigned as a letter grade which excludes all extra
credit points. Then I will apply a subjective method to determine how much
value to assign to extra credit points. Extra credit points can only be
used to raise your final course letter grade. In other words, you are not
obligated to do any of the extra credit work, and you can still get an A in
this course.
A note of caution: in the past, some students have spent
too much time working challenge problems and gotten behind on core assignments;
note that the relative value of extra credit is small compared to the main
course assignments.
Each lab will be worth a given number of points, as listed below.
Groups: You may form groups of up to three students for the assignments. All group members must be enrolled in the course, and listed in comments in the handed-in assignment.
Deadbeats: All group members are responsible for all code that is handed in. Group members are responsible for ejecting students that are not contributing, or adjusting group composition on future assignments. A word to the wise: Think carefully about who you work with - a poor group member can harm your grade beyond repair. Further, it is my experience that when students do not substantially participate in programming homeworks, but rather let their partner(s) do the work for them, they tend to perform poorly on exams.
The instructor reserves the right to quiz or otherwise question any student about their understanding of work handed in; failure to explain the code satisfactorily is grounds for losing all points on the assignment. If an assignment is found to constitute academic dishonesty, all group members are considered responsible and will all be reported to Honor Court.
Changing Groups: You may change or reform groups on any assignment, with the exception of Labs 1 and 2. You need not keep the same group from assignment to assignment after Lab 2. Because Lab 0 builds upon your code for Lab 1, you may not change groups without instructor consent, and this will require explicit guidance on which base code to use for subsequent assignments
The exams will either be take-home or in-person. If they are in-person, they will be closed book. If the exams are take-home, they will be open-book. If exams are open book, reasonable use of internet resources is allowed, but collaboration or asking for help from others via the internet is disallowed.
Special offer: you can write your own exam questions! Submit a question with your solution to course staff in advance of the exam, and if we like it, it will appear on the exam.
The out-of-class work in this course will consist of three types of activities:
Reading from the textbook, assigned papers, and
Linux source code. The main purpose of reading is to
provide you with other means to learn the material.
Reading in advance of class and giving the basics time to digest
also helps one understand more subtle concepts that are
explained in class.
You obviously won't be graded on the readings per se, but
reading can improve your exam scores.
Note also that you are resposible for reading all of the
posts on the class mailing list (on Piazza this semester).
The list will be an invaluable
informational resource for you throughout the class (that's why you
must subscribe to it).
Worksheets handed out in class. You are expected to complete these in teams, in order to help you gain experience reasoning about the issues discussed in class. The worksheets will not be graded, but can affect your participation grade (directly) and working them should improve your exam scores.
Labs in which you will gain hands-on experience using operating system features. Each homework assignment will be graded, and you will be expected to do this alone or with a team.
Reading will take place on an ongoing basis throughout the semester. There will be roughly five programming assignments, with each assignment due a few weeks after it is issued. If you work with a partner, all members you should understand the code, as the exam will also include questions about the labs.
You may work alone or with a partner on all labs. You may change partners between assignments. Larger partnerships will not be permitted.
The course final is given in compliance with UNC final exam regulations and according to the UNC Final Exam calendar.
Each student has 72 late hours to be used at his/her discretion on programming assignments throughout the semester. After your late hours are exhausted, each additional day late will incur a full letter grade penalty. In your lab handin code, you must include a file called slack.txt that lists how many late hours you have used.
Late hours are not divided by teams. For instance, if a team hands in an assignment one hour late, each team member will use one late hour, or take a letter grade penalty.
Conflicts with other courses, research deadlines, holidays, etc. are unavoidable. Thus, you are expected to budget these to account for your other obligations, as well as plan ahead and start early.
The lowest grade you will receive for lateness is a D. If you turn nothing in by the last day of classes for a given lab, you will get an F for that lab. If you turn in all programming assignments on the last day, late assignments may receive up to 60% of the credit.
I would recommend turning in what you have by the deadline for a lab, and then submit an updated version late if it will improve your grade after the deducted late penalties. Course staff will generally not grade labs until several days to a week after they are turned in.
Exemptions to the lateness rule will be allowed in three cases:
No extensions will be given for any other reason.
All enrolled students must complete the academic integrity homework on Gradescope. Course staff will not grade any assignments for a student until this form is received.
Students are encouraged to work together on written homeworks (worksheets), and to study together. The policies below apply to programming assignments (labs).
In the labs you may work as a team. If you work alone, you submit your own work. If you work in a team, what you submit may only have been written by team members, and all team members should understand and have contributed to the code handed in. Whether or not you work in a team, you may discuss the programming assignments with anyone you like in general terms, but you may not share code with anyone other than your teammates.
The code you and your partner submit must be your own work, and only your own work. Failure to document/attribute which students in the class contributed to the assignment is grounds for all students losing points on the lab. Using outside sources (the internet, previous courses, help from anyone not enrolled in the course or course staff), constitutes academic dishonesty and will be referred to the student attorney general. Any evidence that source code has been copied, shared, or transmitted in any way between non-teammates (this includes using source code written by others in previous semesters, or at other universities!) will be regarded as evidence of academic dishonesty.
Handing in someone else's work is expressly forbidden.
Some more specific guidelines for the labs:
Note that the course staff will use tools such as MOSS to detect cheating. These tools are very good at comparing large sets of programing assignments and correlating those that have a shared code basis, even if the code has been changed significantly!
You are welcome to use existing public libraries in your programming assignments (such as public classes for queues, trees, etc.), unless otherwise noted. You may also look at operating systems code for public domain software such as Linux. Such activities qualify under approved collaboration practices, and you are welcome to take advantage of them. Note that you must cite and acknowledge those sources properly. Not doing so constitutes academic plagiarism, and will not be tolerated.
I am very serious about not tolerating academic dishonesty. Unacceptable collaboration, copying or unapproved use of any code, or failure to attribute sources used to formulate a homework solution will be considered a violation of the UNC Honor Code and will be reported to the Student Attorney General.
Intellectual dishonesty can end your career, and it is your responsibility to stay on the right side of the line. If you are not sure about something, ask.
Let me also appeal to your better nature, and remind you of what you will miss out on if you engage in dishonest behavior.
This is a demanding course, and computer science is a demanding major. A successful CS student will learn many skills that are in high demand on the job market. In this course, I hope you will learn to do low-level system programming---a very valuable skill.
It is my experience that there are some skills that can only be learned through struggling with a problem, such as debugging a complex system or synchronization design. If you "take a shortcut" by cheating, you will nominally complete the assignment, but you are cheating yourself of learning how to fix these problems in the future.
By analogy, this class is like signing up with a personal trainer. If you tell your trainer you did all your exercises while she had her back turned, are you actually going to be stronger?
When you graduate, I hope you will get a good job. Your employer and colleagues will expect you to be a master programmer. If you are not a master programmer, you will not be if you violate the academic integrity policy, and you will not have a long or rewarding career.
In summary, these academic honesty guidelines are in your long-term interest.
University Policy: As stated in the University’s Class Attendance Policy, no right or privilege exists that permits a student to be absent from any class meetings, except for these University Approved Absences:
Class Policy: Instructors may work with students to meet attendance needs that do not fall within University approved absences. For situations when an absence is not University approved (e.g., a job interview or club activity), instructors determine their own approach to missed classes and make-up assessment and assignments.
University Approved Absence Office (UAAO): The UAAO website provides information and FAQs for students and faculty related to University Approved Absences. Note: Instructors have the authority to make academic adjustments without official notice from the UAAO. In other words, it is not required for instructors to receive a University Approved Absence notification in order to work with a student. In fact, instructors are encouraged to work directly with students when possible.
Any student who is impacted by discrimination, harassment, interpersonal (relationship) violence, sexual violence, sexual exploitation, or stalking is encouraged to seek resources on campus or in the community. Reports can be made online to the EOC at https://eoc.unc.edu/report-an-incident/. Please contact the University’s Title IX Coordinator (Elizabeth Hall, interim – titleixcoordinator@unc.edu), Report and Response Coordinators in the Equal Opportunity and Compliance Office (reportandresponse@unc.edu), Counseling and Psychological Services (confidential), or the Gender Violence Services Coordinators (gvsc@unc.edu; confidential) to discuss your specific needs. Additional resources are available at safe.unc.edu.
The University of North Carolina at Chapel Hill facilitates the implementation of reasonable accommodations, including resources and services, for students with disabilities, chronic medical conditions, a temporary disability or pregnancy complications resulting in barriers to fully accessing University courses, programs and activities.
Accommodations are determined through the Office of Accessibility Resources and Service (ARS) for individuals with documented qualifying disabilities in accordance with applicable state and federal laws. See the ARS Website for contact information: https://ars.unc.edu or email ars@unc.edu.
The professor reserves to right to make changes to the syllabus, including project due dates and test dates. These changes will be announced as early as possible.
UNC-Chapel Hill is strongly committed to addressing the mental health needs of a diverse student body. The Heels Care Network website (https://care.unc.edu) is a place to access the many mental resources at Carolina. CAPS is the primary mental health provider for students, offering timely access to consultation and connection to clinically appropriate services. Go to their website https://caps.unc.edu/ or visit their facilities on the third floor of the Campus Health building for an initial evaluation to learn more.
Portions of this course design, organization, policies, syllabus, web design, etc. came from Gene Stark, Erez Zadok, Michael Bender, Michael Ferdman, and Kevin Jeffay.
Last updated: 2022-11-03 10:50:47 -0400 [validate xhtml]