This is not the current version of the class.

Lecture 9

A topic we want to cover in this class is the design of debugging aids for large systems. Kernel correctness is incredibly important, so kernel authors build extensive debugging and self-checking infrastructure into their systems. But kernels are deployed in challenging situations, so debugging tools designed more for simple, user-level processes don’t always apply. We can add a lot to our debugging toolboxes by considering how kernel designers make their systems more robust. Today, we consider the spinlock subsystem. By the end of class we hopefully will improve Chickadee’s spinlock debuggability.

Part 1: Survey

In the first part, we’ll look at other operating systems’ spinlocks and characterize their debugging and robustness features, and differences from Chickadee’s spinlocks.

Every group will want to familiarize themselves with Chickadee’s k-spinlock.hh. Then each group should choose an operating system. Here’s a selection. FreeBSD and Linux’s implementations are far more complex. Each group should tackle another one teaching OS and then one real OS. Are the teaching OS features mirrored in the real OS? Does the real OS have more features? What features?

OS/161 teaching operating system

xv6 teaching operating system

FreeBSD operating system

Linux operating system

Part 2: Recommendations

Spend the half hour of class looking at code, dividing up work, and talking with your group about what you see. Spend the second half hour of class developing a proposal for changes to Chickadee’s k-lock.hh file to make it more debuggable. Mention features you found in the other operating systems that should not be ported to Chickadee, as well as features that should. Outline implementations if you can. Develop a short presentation about your ideas (Google doc preferred).

Part 3: Presentations and discussion

Each group will present their ideas; we’ll discuss, implement, and conclude.