Download OS_Structure

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
C SOURCE FILES:
Initialization
Main kernel
Terminal handler
File System
Memory Management
Process Comm.
Quota Management
System Call Table
Miscellaneous
VAX-specific
TOTAL
C HEADER FILES:
Machine Indep.
VAX-specific
TOTAL
ASSEMBLER FILES
VAX-specific
GRAND TOTAL
No. of MODULES
No. of LINES
2
15
7
12
12
8
4
1
8
18
87
548
4683
2959
5573
4582
3110
1391
162
2237
4905
30150
61
20
81
4150
1275
5425
1
169
1231
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
Memory mapped I/O
Application
program and Data
0
Resident components,
interrupt vectors
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.
System Call
Routine A
Resident Modules
M
Routine A
E
Routine B
M
Routine C
O
Routine D
R
Y
Routine F
System Call
Routine F
Transient Modules
Routine D
Routine E
Routine F
Traditional execution organization
All Devices
Calling
Program
System
Routine A
All Instructions
All Registers
System Processes
User
process
Program
requests
system
service
System
process
Create
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
Create Process
Destroy Process
Initialize Process
Display Process
Block Process
PCB Data Type
Module B, Scheduling
Load Program
Run Program
Suspend Program
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.