Operating Systems :: CS 332 :: Winter 2022

Contact Information

Course Information

Course Time: 4a (MW 12:30pm – 1:40pm, F 1:10pm – 2:10pm)

Office Hourse: Mondays 4:30pm – 5:30pm and Wednesdays 10:00am – 11:30am in my office (Olin 339) and Thursdays 7:30pm – 9:30pm in the lab (Olin 310)

Course Text: Operating Systems: Three Easy Pieces (OSTEP), Arpaci-Dusseau and Arpaci-Dusseau
This free, online textbook will be the primary book for the course. The full, bookmarked pdf is linked from Moodle.

I will also assign readings from Operating Systems: Principles and Practice (OSPP), 2014 (2nd Edition), Anderson and Dahlin when I feel it improves significantly on the OSTEP book. These will always be provided as scans on Moodle.

Announcements will be made via Moodle, so watch for those emails.

Programming Environment: This course will include work in C. Lab assignments will need to be completed on a x86-64 Linux machine with gcc and qemu. There are two main options for this: work on a CS department server or on your local computer.

I generally recommend working on a CS server, as it involves a lot less setup. This course will use mantis.mathcs.carleton.edu. This is a Linux server running Ubuntu 18. The easiest way to access it is via the VS Code Remote SSH extension, though command-line ssh will also work. See this SSH tutorial. The main downside to working on a CS server is that you need an internet connection.

If you want to work on your local machine, and your computer is Mac or Windows, you will need to set up a separate Linux environment. On Windows 10 or 11, this is pretty easy, thanks to the Windows Subsystem for Linux. Follow this guide to set it up. On Mac and earlier versions of Windows, you will need to run a Linux virtual machine (VM). You can find instructions for the official CS VM on the Carleton wiki. The CS VM is quite large (11GB download, ~30 GB expanded, courtesy of lots of useful pre-installed stuff). If that's a problem for you, consider using the much smaller Xubuntu VM from osboxes.org. Like the CS VM, you will want the free VirtualBox to run the VM. If you run into any problems, please post questions to the Moodle forum or Slack.

Course Links

• Communications
  • Moodle Forum
  • Anonymous Feedback
• Resources
  • 332 style guide
  • Remote access with SSH
  • The Unix command line
    • Linux tutorial
    • Bash commands, Ruth Anderson, University of Washington
    • Some useful Unix commands, Tia Newhall, Swarthmore College
  • git resources
    git - the simple guide (my favorite)
    git handbook (includes information about GitHub)
    git website / book
    
  • The C Programming Language
    • Best standard library reference: cplusplus.com
    • Stanford CS Library C resources
    • C resources, Tia Newhall, Swarthmore College
    • Duane’s Incredibly Brief Introduction to the C Programming Language, Duane Bailey, Williams College
    • C for Python programmers
    • C for Java programmers
    • C Programming WikiBook
  • Using make and writing Makefiles
  • GDB: gdb ./executable
    • Beej's Quick Guide to GDB (based on the very handy gdb -tui mode)
    • Two-page x86-64 GDB cheat sheet (pdf, txt)
    • Examining Memory
    • Extensive Tutorial
    • TUI commands

Course Description

If you're working in the lab, you might be editing a file while waiting for a program to compile. Meanwhile, the on-screen clock ticks, a program keeps watch for incoming e-mail, and other users can log onto your machine from elsewhere in the network. Not only that, but if you write a program that reads from a file on the hard drive, you are not expected to concern yourself with turning on the drive's motor or moving the read/write arms to the proper location over the disk's surface. Coordinating all this hardware and software is the job of the operating system. In this course we will study the fundamentals of operating system design, including the operating system kernel, scheduling and concurrency, memory management, and file systems.

• Efficiently explore a large, complex codebase written by other people
• Apply principles of isolation and privileged execution to design robust and secure software
• Identify situations where concurrent execution poses problems such as race conditions and deadlock
• Appropriately use synchronization primitives like locks and condition variables to resolve these problems
• Explain the role of virtualization in sharing resources and providing useful illusions
• Describe in detail how threads provide parallelism and concurrency

Course Policies

Grading breakdown:

• 50% from Labs (500 points): one short, introductory lab and five substantial programming labs. You can work with a partner or by yourself.
• 14% from Quizzes (140 points): there will be a short online quiz most weeks in this course. These quizzes will check your comprehension of the material, and whether you are able to apply the concepts you've seen in class/on assignments in different contexts. They will have no time limit and you will be allowed to attempt them any number of times.
• 20% from Design (200 points): labs 2–5 will each have a design component consisting of two stages: design document and peer feedback.
• 16% from a Final Project (160 points): an open-ended final project of your own design extending the lab operating system.

Late Policy: Deadlines will be given with each assignment. These deadlines are strict. There will be no credit for late work. For the entire term, you have four late days. You are advised to use them conservatively. On group projects you may only use late days if all members of the group have them available, and all members of the group will be charged for each late day used. They must be used in 24-hour (integer) chunks. One or more late days can be activated on an assignment by emailing me before the assignment is due. There is no penalty whatsoever associated with using a late day. This policy may not be the same as in your other classes. You are responsible for understanding it if you choose to submit late work.

A note on inclusivity:

please treat your classmates with kindness and respect, both inside the classroom and out. Classrooms can be vulnerable environments; asking questions and expanding our understanding of new concepts requires us to reveal over and over again that we don't fully know something. It's okay to not know everything immediately! It's not okay to make people feel bad about what they don't know. This can happen even in subtle ways - see this page for a few ideas on how to help create a friendly learning environment. Our individual differences enrich and enhance our understanding of one another and of the world around us. This class welcomes the perspectives of all ethnicities, genders, religions, ages, sexual orientations, disabilities, socioeconomic backgrounds, regions, and nationalities.

Academic Honesty and Collaboration: (adapted from Academic Integrity at MIT)

Writing code is similar to academic writing in that when you use or adapt code developed by someone else as part of your project, you must cite your source. However, instead of quoting or paraphrasing a source, you include an inline comment in the code. These comments not only ensure you are giving proper credit, but help with code understanding and debugging. For these comments, the URL and the date of retrieval are generally sufficient. Add more details if it will help the reader get a clearer understanding of the source.

Labs in this class are intended to be primarily individual efforts or an equal collaboration between you and your partner (on labs that explicitly state they may be done with a partner). You are encouraged to discuss approaches with other students but your code and your write-up must be your own.

You may not use materials produced as course work by other students, whether in this term or previous terms, nor may you provide work for other students to use.

It's good to help other students. But as a general rule, during the time that you are helping another student, your own solution should not be visible, either to you or to them. Make a habit of closing your laptop while you're helping. You should never be in possession of a (paper or electronic) copy of a classmate's code before the due date for the assignment. Another way to articulate this: when getting help, that consultation should be in English and not in code.

It's fine to use material from external sources like StackOverflow, but only with proper attribution, and only if the assignment allows it. In particular, if the assignment says "implement X," then you must create your own X, not reuse one from an external source.

It's also fine to use any code I provide, without need for attribution.

Example 1

• Alyssa and Ben sit next to each other with their laptops while working on a problem set. They talk in general terms about different approaches to doing the problem set. They draw diagrams on the whiteboard. When Alyssa discovers a useful class in the Java library, she mentions it to Ben. When Ben finds a StackOverflow answer that helps, he sends the URL to Alyssa. OK.
• As they type lines of code, they speak the code aloud to the other person, to make sure both people have the right code. INAPPROPRIATE.
• In a tricky part of the problem set, Alyssa and Ben look at each other's screens and compare them so that they can get their code right. INAPPROPRIATE.

• Juan already finished the problem set, but his friend Boris is now struggling with a nasty bug. Juan sits next to Boris, looks at his code, and helps him debug. OK.
• Juan opens his own laptop, finds his solution to the problem set, and refers to it while he's helping Boris correct his code. INAPPROPRIATE.

• Yun-En had three problem sets and two quizzes this week, was away from campus for several days for a track meet, and then got sick. He's already taken two slack days on the deadline and has made almost no progress on the problem set. Sven feels sorry for Yun-En and wants to help, so he sits down with Yun-En and talks with him about how to do the problem set while Yun-En is working on it. Sven already handed in his own solution, but he doesn't open his own laptop to look at it while he's helping Yun-En. OK.
• Sven opens his laptop and reads his own code while he's helping Yun-En. INAPPROPRIATE.
• Sven has by now spent a couple hours with Yun-En, and Yun-En still needs help, but Sven really needs to get back to his own work. He puts his code in a Dropbox and shares it with Yun-En, after Yun-En promises only to look at it when he really has to. INAPPROPRIATE.

• Amir and Prajna both worked on their problem sets separately. They exchange their test cases with each other to check their work. INAPPROPRIATE. Test cases are part of the material for the problem set, and part of the learning experience of the course. You are copying if you use somebody else's test cases, even if temporarily.

Academic Accommodations:

Carleton College is committed to providing equitable access to learning opportunities for all students. The Office of Accessibility Resources (Henry House, 107 Union Street) is the campus office that collaborates with students who have disabilities to provide and/or arrange reasonable accommodations. If you have, or think you may have, a disability (e.g., mental health, attentional, learning, autism spectrum disorders, chronic health, traumatic brain injury and concussions, vision, hearing, mobility, or speech impairments), please contact OAR@carleton.edu or call Sam Thayer ('10), Director of the Office of Accessibility Resources (x4464), to arrange a confidential discussion regarding equitable access and reasonable accommodations.