Operating System Overview

An operating system sits between the hardware and every piece of software above it. It has to run right against the hardware, and yet it has to hand the applications on top of it a set of stable abstractions. This chapter answers three questions in turn: what actually counts as an operating system, where operating systems came from and how they are classified, and finally how they run in practice and how they are put together.

The first question has two handles. Look at the four defining characteristics — concurrency, sharing, virtualization, and asynchronism — and at the five core functions: process management, memory management, file management, device management, and the user interface. Hold any system up against these two lists and you can explain, in concrete terms, why it is an operating system.

The second question is about where the field came from and where it is heading. Seven generations of development — manual operation, batch processing, time sharing, real time, networked, distributed, and embedded — were pushed forward by hardware and by user demand at the same time. And once you sort systems four different ways, by number of users, by the way tasks are processed, by response time, and by application domain, the same system can finally say plainly what it is.

The third question is about running and building. Kernel mode and user mode draw the privilege boundary; interrupts and exceptions explain how a running program is taken over before it gets out of control; system calls are the legitimate way in from user mode into the kernel. And the five architectures — monolithic kernel, microkernel, layered, modular, and hybrid — answer the question of where the complexity should live.

By the end of this chapter you should be able to decide whether an unfamiliar system is an operating system at all, describe its evolutionary lineage and where it sits in the taxonomy, and explain the basic trade-offs behind switching privilege levels and choosing an architecture.