Operating-System Layered Approach

With proper hardware support, operating systems can be broken into pieces
that are smaller and more appropriate than those allowed by the original
MS-DOS or UNIX systems. The operating system can then retain much greater
control over the computer and over the applications that make use of that
computer. Implementers have more freedom in changing the inner workings
of the system and in creating modular operating systems. Under the topdown
approach, the overall functionality and features are determined and are separated into components. Information hiding is also important, because it
leaves programmers free to implement the low-level routines as they see fit,
provided that the external interface of the routine stays unchanged and that
the routine itself performs the advertised task.

A system can be made modular in many ways. One method is the layered

approach, in which the operating system is broken up into a number of layers

(levels). The bottom layer (layer 0) is the hardware; the highest (layer N) is the

user interface. This layering structure is depicted in Figure 2.12.

An operating-system layer is an implementation of an abstract object made

up of data and the operations that can manipulate those data. A typical

operating-system layer—say, layer M—consists of data structures and a set

of routines that can be invoked by higher-level layers. Layer M, in turn, can

invoke operations on lower-level layers.

The main advantage of the layered approach is simplicity of construction

and debugging. The layers are selected so that each uses functions (operations)

and services of only lower-level layers. This approach simplifies debugging

and system verification. The first layer can be debugged without any concern

for the rest of the system, because, by definition, it uses only the basic hardware

(which is assumed correct) to implement its functions. Once the first layer is

debugged, its correct functioning can be assumed while the second layer is

debugged, and so on. If an error is found during the debugging of a particular

layer, the error must be on that layer, because the layers below it are already

debugged. Thus, the design and implementation of the system is simplified.

Each layer is implemented with only those operations provided by lowerlevel

layers. A layer does not need to know how these operations are

implemented; it needs to know only what these operations do. Hence, each

layer hides the existence of certain data structures, operations, and hardware

from higher-level layers.

The major difficulty with the layered approach involves appropriately

defining the various layers. Because a layer can use only lower-level layers,

careful planning is necessary. For example, the device driver for the backing store (disk space used by virtual-memory algorithms) must be at a lower

level than the memory-management routines, because memory management

requires the ability to use the backing store.

Other requirements may not be so obvious. The backing-store driver would

normally be above the CPU scheduler, because the driver may need to wait for

I/O and the CPU can be rescheduled during this time. However, on a large

system, the CPU scheduler may have more information about all the active

processes than can fit in memory. Therefore, this information may need to be

swapped in and out of memory, requiring the backing-store driver routine to

be below the CPU scheduler.

A final problem with layered implementations is that they tend to be less

efficient than other types. For instance, when a user program executes an I/O

operation, it executes a system call that is trapped to the I/O layer, which calls

the memory-management layer, which in turn calls the CPU-scheduling layer,

which is then passed to the hardware. At each layer, the parameters may be

modified, data may need to be passed, and so on. Each layer adds overhead to

the system call; the net result is a system call that takes longer than does one

on a nonlayered system.

These limitations have caused a small backlash against layering in recent

years. Fewer layers with more functionality are being designed, providing most

of the advantages of modularized code while avoiding the difficult problems

of laver definition and interaction.