Operating System Structure

OS Design Considerations:• How are the responsibilities of the OS divided

among various modules? • When and where are various parts of the OS

loaded in memory? • When and how are specific components

executed? • How do distinct components interact and affect

each other? • How can partitioning the OS make it easier to

adapt to new requirements?

• An OS must provide many services:– Process management & program execution– Main Memory management– File Management

• Such a complex piece of software can only be produced by dividing it into modules

• Most operating systems are very large:– MVS ½ billion bytes of information– Linux 100’s of thousands of lines of code– Complete Windows XP installation 50 million

lines of source code

Issues which affect organizational structure

• Source Code Organization• Storage Organization• Execution Conditions• Component Interaction• Hardware Control• Adaptability

Source code organization

• Division into modules– The program code comprising a complex operating

system is normally organized into small program units, such as procedures, to make it possible to design, develop and maintain the system without being overwhelmed by its complexity.

– These modules should be defined so that related elements are grouped together as much as possible. For example, the principal data structures used for process management, should be grouped together with procedures that operate on processes.

Figure 11--1: The Software System Construction Process

How do we divide a system into Modules• All the code and data used for one distinct task

should be placed together. (encapsulation)• Each module should only have access to

information it really needs, and should not be able to directly access information contained in other modules (Information Hiding)

• Each module should interact with only a small number of others.

• Interaction between modules should use simple, well-defined interfaces. (method or procedure calls)

• Most anticipated design changes should affect only a small number of modules.

Code Structure Examples

• Your text provides two examples of how to organize the source code associated with an OS.

• MS-DOS:– The OS includes 3 distinct parts that reflect the principal

resource management functions:– BIOS (Basic I/O system) for device management– The OS itself– Command.com which was the command handler for the user

interface.• Unix: (version 4.2 Berkley Unix)• The version of Unix illustrated was developed for the

VAX. – The main body of source code consisted of 100 files, and about

35,000 lines of C code.– A typical file is a few hundred lines long, and contains several

related procedures.

• CLASS No. of MODULES No. of LINES• C SOURCE FILES:• Initialization 2 548• Main kernel 15 4683• Terminal handler 7 2959• File System 12 5573• Memory Management 12 4582• Process Comm. 8 3110• Quota Management 4 1391• System Call Table 1 162• Miscellaneous 8 2237• VAX-specific 18 4905• TOTAL 87 30150• C HEADER FILES:• Machine Indep. 61 4150• VAX-specific 20 1275• TOTAL 81 5425• ASSEMBLER FILES• VAX-specific 1 1231• GRAND TOTAL 169 36806•  • Figure 11-3 Source Modules for Berkeley 4.2 UNIX

Implementation Languages• Most early OS’s were written as huge nests of Assembler language

statements– Believed that programs written directly in assembly language by

experienced developers was more efficient.– Assembly language provides easier access to directly control physical

resources• This is changing for many reasons

– Modern OS’s are so complex that they are almost impossible to manage without the more powerful control and data structures provided by high level languages.

– Reliability of an OS is very important, Well structured code written in a high level languages and error checking compilers increase reliability.

– Newer SIL (system implementation languages) produce highly efficient code.

– Portability

Many OS’s have been written in high level languages

• MCP (master control Program) for Burroughs computers was written in a variant of ALGOL.

• MULTICS was written mainly in PL/1 • UNIX, OS/2 (IBM dos Rival), & Windows NT are written

mainly in C. (eventually all of the kernel of Unix was rewritten in C)

• Only 900 lines of code of the original UNIX was written in assembly language which was primarily scheduler and device drivers but eventually all of the kernel was rewritten in C

• CP/M was written in a scalled down version of PL/I, PL/M

Storage organization• A running OS is divided into components that

may occupy storage in various locations and for different periods of time.

• Some components may remain in memory at all times, while others are loaded when required.

• Additionally, some components may always be placed in the same memory location when loaded.

• A related but distinct issue is the form and location of master copies of each component, usually on secondary storage.

Resident components

• These components are responsible for critical services that must be available no matter what programs are running.

• These services include process dispatching, timing, enforcement of security, error handling, access control, and initial handling of resource requests.

• The limited portion of the OS that performs these functions is sometimes called the nucleus or kernel.

• Since the continued operation of a computer system depends on the integrity of the resident components of the OS, destruction of these components must be avoided. – In some computers the resident components are stored in read-only

memory, ensuring that the OS remains permanently resident and cannot be destroyed.

– However, such an OS can be modified or upgraded only by physically replacing the read-only memory.

• In most other computers, the resident OS resides in ordinary memory. If it is damaged, it can be reloaded from secondary storage, which usually requires a complete initialization of the operating system.

Transient Components

• Transient components are needed less frequently and are be loaded from files, and executed only as needed to provide specific user services.

• Resident and transient components can be loaded into memory in various locations, how an individual OS use storage varies greatly.

• Normally resident components are loaded into the areas of memory with the lowest addresses.

• Application programs begin being loaded at a location just beyond the portion of the os in low memory.

• Some OS’s divide the resident portions of the os between the lowest and highest portions of memory leaving the area in between for application programs.

• Transient components are loaded in the space for application programs.

Component layout

Resident components, interrupt vectors0

Application program and Data

Resident components

Memory mapped I/O

Execution conditions• The program code of an operating system is divided into executable

units. • Specific events cause execution of each unit. • Many portions of the OS are executed by specific request of a

program, as by a call instruction, or in response to interrupts or other separate events.

• When these components are invoked, they may complete their work before returning to the program, or they may schedule work for completion later. Once begun, they may be subject to interruption by more urgent units.

• Many units of the operating system may execute with privileges, enforced by hardware, which are not available to application programs. They may be permitted to execute privileged instructions that affect system control registers, and they may be able to access memory that most other programs cannot use.

Resident Modules

Routine A

Routine B

Routine C

M

E

M

O

R

Y

System Call Routine A

System Call Routine F

Routine F

Transient Modules

Routine D

Routine E

Routine F

Routine D

Traditional execution organization

System Routine A

Calling Program

All Devices

All Instructions

All Registers

System Processes

Program requests system service

Create system process

User process

System process

User process

System process

User process

Component Interaction

• Each executable unit of an OS may be restricted to making use of other program and data units only in limited ways.

• This technique often results in a structure based on levels, in which a few components control critical hardware resources and provide essential services. Other components access these low level components rather than accessing resources directly.

Unstructured interaction• In most early operating systems, no attempt was made

to control or restrict interaction between separate modules.

• any procedure could be called by any other, and any data could be referenced by any procedure.

• For all but the smallest systems, such an unstructured

approach leads to a highly unreliable system. It is difficult or impossible to predict the effects of any changes because we cannot determine which parts of the system rely on the procedures or data that were changed.

• Because of this problem, it is necessary to restrict the set of procedures and data that a given procedure can access.

Modular Design

Module A, Process Management

Module B, Scheduling

Create Process

Initialize Process

Destroy Process

Display Process

Load Program

Suspend Program

Run Program

Block Process

PCB Data Type

Isolation of Modules• The concept of limiting interaction with the aid of

compilers or hardware has been an important tool in the organization of many OSs written in high-level languages.

• In most cases, modules are grouped according to the major function they support, such as memory management.

• Common data structures that support each function can be accessed only by the relevant modules.

Levels and Abstract machines

Figure 11--11: A Level-Structured Operating System

Hardware control• Another important consideration in organizing the components of an

operating system is the close dependency between some OS functions and portions of the computer hardware. – Components must be identified that control and interact with

various subsystems of the computer hardware, especially specific types of I/O devices.

– These subsystems may differ among system installations, which means they are the most frequently replaced or modified.

– In addition, some hardware systems may vary in structure or some devices/components may be omitted in different installations of the same operating system.

– These components of the system must be tailored to match the actual hardware available.

• It is imperative that the components of an OS that manages hardware be customizable to a specific installation. When the OS is generated, the generation script may ask the installer questions about the hardware setup or even run diagnostics to determine the type and number of devices present.

Adaptability• An operating system must be modified from time to time to

match the needs and resources of a new installation, or changing conditions at an existing installation.

• Components may be identified that can be modified in controlled ways to meet these requirements. Some components may be replaceable as a whole, or their use may be optional.

• Must ensure that our organization supports ease of maintenance.

• Periodically, improvements or corrections to the operating system may be required. It should be possible to update subsystems, such as memory management or file management, without the need to change other portions of the OS.

• It is also critical that a new version of an OS be installable with minimal disruption to its users. It would be unacceptable if a new OS version required all software to be recompiled because addresses within the OS had changed. The system call instruction plays an important role here; it provides a means for accessing the OS that will not change unnecessarily when new versions are developed.

• Requirements and applications may also change or vary at different installations, leading in some cases to the need for distinct differences in OS structure.