[Kernel, courtesy IowaFarmer.com CornCam]

CS 261 Research Topics in Operating Systems, Fall 2011

Syllabus

Description

Operating systems are the software programs that transform computer hardware interfaces—the bits and bytes required to direct the CPU and other attached devices—into an abstract interface that is both safer and more convenient to program. Operating systems are hard-core programs: hard to write, hard to reason about, and critically important for performance. This makes them exciting too!

Most of today’s operating systems, including many of those for embedded devices, share a similar abstract interface (Unix-like, file-based) and a similar implementation strategy (a monolithic kernel). However, operating system evolution is by no means complete. Operating systems continue to incorporate great ideas from other areas of computer science. Application programs from browsers to massive storage systems have developed OS-like characteristics, such as the need to juggle competing clients. Careful analysis of system call interfaces highlights the interface design issues at the core of any performance-sensitive programming task.

The purpose of this class is to open up and demystify operating systems as a field for investigation, effort, and research. We demystify operating systems as programs by building our own OS, an low-level “exokernel” OS, which runs on real Intel hardware; and we demystify operating systems research through critical treatment of historical and recent research work, with special attention to interfaces.

This class is based on several beliefs:

  • That implementing low-level systems is important, empowering, and useful.
  • That unusual system organizations open the mind.
  • That small systems are great platforms for evaluating new ideas.
  • That useful “hacks” matter.

Notes

The JOS operating system that’s the focus of these labs is not dissimilar from OS/161, Nachos, or other skeleton operating systems you have seen in earlier classes. However, these operating systems are generally more conventional in organization than JOS and run only on simulated hardware. You should get something from implementing JOS even if given experience with OS/161.

Course objectives

After this course, you should be able to:

  • Build a near-complete operating system for an x86 machine.
  • Map operating system functionality to virtual memory manipulations.
  • Evaluate system interfaces for functionality, usability, and performance.
  • Design new systems interfaces and implementation techniques.
  • Read systems papers critically.
  • Extract important techniques from systems research and adapt them to new contexts.
  • Identify systems research problems.
  • Create and execute a systems research plan.

Assignments

The main coursework is a series of structured labs, based around skeleton code, through which you build your own exokernel-based operating system. In each lab you will complete all the assigned problems as well as one or more challenge problems, in which you push your operating system in less structured directions. Labs must be completed individually.

  • Lab 1: assigned 9/1, due 9/13
  • Lab 2: assigned 9/13, due 9/27
  • Lab 3: assigned 9/27, due 10/11
  • Lab 4: assigned 10/11, due 10/25
  • Lab 5: assigned 10/25, due 11/8

You will complete the structured labs by mid-November and begin work on a research project. You may use your operating system skeleton as a base, design a new operating system architecture from scratch, or work on an existing operating system. Wild ideas are encouraged! You will first outline your ideas in a proposal, then execute that proposal and produce an 8-to-14 page report modeled on a conference paper. Research projects may be executed in teams of up to three (but should involve work proportional to team size).

  • Team formation, research idea sketches and discussion: 10/25-11/8
  • Proposal: due 11/15
  • Final report: due 12/11

You are also responsible for reading papers assigned for class discussion. There will usually be one or two papers per class meeting, which you must read before class. Homework and/or short pop quizzes will confirm you do the reading.

Finally, there will be two in-class tests, a midterm and a “final”, which will cover both reading and labs. The tests are open-book, open-note, closed-computer (nothing electronic allowed).

Grading

  • 30% labs
  • 30% final project
  • 30% tests
  • 10% other homework, class participation
  • Letter grading

Completing all the labs (including a full complement of challenge problems), doing average on the tests and other homework, and executing a well-chosen final project will earn an A-range grade. Not completing the labs will likely prevent you from earning an A-range grade. Excellent work on challenge problems and/or final project will be rewarded.

Policies

Labs and projects are due at midnight (11:59:59pm on the day mentioned).

Lateness: Every student has 72 penalty-free late hours to use over the semester. That is, taken as a whole, homework may be up to 72 cumulative hours late without penalty. (For instance, Lab 1 might be 23 hours, 2 minutes late, which counts as 24 hours; Lab 2 might be 10 hours late; and Lab 3 might be 38 hours late.) Every additional hour of lateness will reduce a late assignment’s grade by the equivalent of a letter grade, down to the equivalent of F. We will assign these penalties so as to give you the best overall grade possible.

Please note that a zero on an assignment is usually much worse than an F. It’s thus better to complete and turn in assignments even if you've already used all your late hours.

No additional consideration for lateness will be given. Use your late hours wisely!

The absolute deadline for assignments is midnight 12/18. Assignments received after that time will be ignored and will earn a zero.

Collaboration: We expect you to discuss the labs with one another, but to complete each lab on your own. Again, the final project can be completed in teams. We also encourage collaboration on particularly difficult lab challenge problems; please contact the instructor to check whether a challenge problem is suitable for team implementation. Collaboration beyond superficial discussion should be acknowledged in the lab manual (for example, “SUPERSTAR Rajinikanth helped me fix my problem 4 implementation”). You don't need to cite discussion on the class mailing list or with the instructor or TF.

Back to CS 261 Research Topics in Operating Systems