Page 35 - DCAP507_SYSTEM_SOFTWARE

Unit 2: Evolution of Operating System

Each layer is implemented using only those operations provided by lower level layers. A layer Notes
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 layer approach to design was first used in the operating system at the Technische Hogeschool
Eindhoven. The system was defined in six layers. The bottom layer was the hardware. The next
layer implemented CPU scheduling. The next layer implemented memory management; the
memory-management scheme was virtual memory. Layer 3 contained device driver for the
operator's console. Because it and I/O buffering (level 4) were placed above memory
management, the device buffers could be placed in virtual memory. The I/O buffering was also
above the operator's console, so that I/O error conditions could be output to the operator's
console.
This approach can be used in many ways.

Example: The Venus system was also designed using a layered approach.
The lower layers (0 to 4), dealing with CPU scheduling and memory management, were then
put into microcode. This decision provided the advantages of additional speed of execution and
a clearly defined interface between the microcoded layers and the higher layers.
The major difficulty with the layered approach involves the appropriate definition of the various
layers. Because a layer can use only those layers that are at a lower level, careful planning is
necessary.

Example: The device driver for the backing store (disk space used by virtual-memory
algorithms) must be at a level lower than that of 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, for a user program to execute an I/O operation, it executes a system call
which is trapped to the I/O layer, which calls the memory-management layer, through to the
CPU scheduling layer, and finally 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 and the net
result is a system call that takes longer than one does on a non-layered 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 layer definition and interaction. For instance,
OS/2 is a descendant of MS-DOS that adds multitasking and dual-mode operation, as well as
other new features.
Because of this added complexity and the more powerful hardware for which OS/2 was designed,
the system was implemented in a more layered fashion. Contrast the MS-DOS structure to that
of the OS/2. It should be clear that, from both the system-design and implementation standpoints,
OS/2 has the advantage.

LOVELY PROFESSIONAL UNIVERSITY 29