Portability :adapt to new environment

Extensibility adapt to new functionalities

Modern operAting systems implement the core of An operAting system in the form of
A kernel or A microkernel, And build the rest of the operAting system by using the
services offered by the core.portAbility of An operAting system is determined
by the properties of its kernel or microkernel. Extensibility of An OS is
determined by the nAture of services offered by the core

Operation of an OS:

Boot procedure: When A COmputer is switched on, the boot procedure AnAlyzes its
confifigurAtion— CPU type, memory size, I/O devices, And detAils of other hArdwAre
connected to the computer (see Section 1.3). It then loAds A pArt of the OS in
memory, initiAlizes its dAtA structures with this informAtion, And hAnds over control
of the computer system to it.
System cAlls leAd to softwAre interrupts
I/O operAton or end of time slice leAds to hArdwAre interrupts

Diagram of OS Operation
 Causes CPU to go to ISR

The interrupt servicing routine performs a context save action to save information about the interrupted program and activates an event handler

NOTE

P2 Scheduler
CPUswitching occurs
twiceduring processingof
the an
P3
perform event handling and then to the process selected by the scheduler.
P4
P1

The scheduler then selects a process and switches the CPU to it.

Structure of an OS:
Policy: A policy is the guiding principle under which the operAting system
will perform the function.
MechAnism: A mechAnism is A specifific ACtion needed to implement A policy.
A policy decides whAt should be done, while A mechAnism determines how
something should be done And ACtuAlly does it.

module that decides whichand

Portability mechanism modules
Extensibility: to call under what conditions.A mechanism is implemented
PortAbility refers to the eAse with which A softwAre
progrAm cAn be ported—it is
inversely proportionAl to the porting effort. Extensibility refers to the eAse with
which new functionAlities cAn be Added to A softwAre system. Porting of An OS
chAnging pArts of its code thAt Are Architecture
dependent so thAt the OS cAn work with new hArdwAre. An OS would hAVe high
portA bility if its Architecture-dependent code is smAll in size, And its complete code
is structured such thAt the porting effort is determined by the size of the
Architecture dependent code, rAther thAn by the size of its complete code.the issue
of OS portAbility is Addressed by sepArAting the Architecture-dependent And
Architecture-independent pArts of An OS And providing well-defifined
interfACes between the two pArts.
Extensibility of An OS is needed for two purposes: for incorporAting new
hArdwAre in A COmputer system—typicAlly new I/O devices or network AdApters—
And for providing new functionAlities in response to new user expectAtions
It would
check for hArdwAre thAt wAs not present when the OS wAs lAst booted, And either
prompt the user to select AppropriAte softwAre to hAndle the new hArdwAre, typ
icAlly A set of routines cAlled A device driver thAt hAndled the new device, or itself
select such softwAre. The new softwAre wAs then loAded And integrAted with the
kernel so thAt it would be invoked And used AppropriAtely. Modern operAting
systems go A step further by providing A plug-And-plAy cApAbility, whereby new
hArdwAre cAn be Added even while An OS is in operAtion. The OS hAndles the
interrupt cAused by Addition of new hArdwAre, selects the AppropriAte softwAre,
And integrAtes it with the kernel.

OPERATING STYSTEMS WITH MONOLITHIC STRUCTURE

It is designed to consist of A set of softwAre
modules, where eACh module hAs A well-defifined interfACe thAt must be used to
ACCess Any of its functions or dAtA. Such A design hAs the property thAt A mod
ule cAnnot “see” inner detAils of functioning of other modules. This property
simplififies design, coding And testing of An OS.
EArly operAting systems hAd A monolithic structure, whereby the OS formed
A single softwAre lAyer between the user And the bAre mAChine, i.e., the computer
system’s hArdwAre (see Figure 4.2). The user interfACe wAs provided by A COm

mAnd interpreter. The commAnd interpreter orgAnized creAtion of user processes.

Both the commAnd interpreter And user processes invoked OS functionAlities And
services through system cAlls.
Two kinds of problems with the monolithic structure were reAlized over A

period of time. The sole OS lAyer hAd An interfACe with the bAre mAChine. Hence
Architecture-dependent code wAs spreAd throughout the OS, And so there wAs
poor portAbility. It Also mAde testing And debugging diffificult, leAding to high
costs of mAintenAnce And enhAncement. These problems led to the seArch for
AlternAtive wAys to structure An OS
LAYERED STRUCTURE

SemAntic GAp The mismAtch between the nAture of operA

tions needed in the ApplicAtion And the nAture of operAtions provided in the
mAChine.
The bAsic discipline in designing A lAyered OS is thAt the routines of one
lAyer must use only the fACilities of the lAyer directly below it—thAt is, no lAyer
in the structure cAn be bypAssed. Further, ACCess to routines of A lower lAyer
must tAke plACe strictly through the interfACe between lAyers. Thus, A routine
situAted in one lAyer does not “know” Addresses of dAtA structures or instruc
tions in the lower lAyer—it only knows how to invoke A routine of the lower
lAyer. This property, which we will cAll informAtion hiding, prevents misuse or
corruption of one lAyer’s dAtA by routines situAted in other lAyers of the OS.
During debugging, locAlizAtion of errors becomes eAsy since the cAuse of An
error in A lAyer, e.g., An incorrect vAlue in its dAtA element, must lie within thAt
lAyer itself. InformAtion hiding Also implies thAt An OS lAyer mAy be modifified
without Affecting other lAyers. These feAtures simplify testing And debugging
of An OS.

The lAyered ApproACh to OS design suffers from three problems.

The
operAtion of A system mAy be slowed down by the lAyered structure.
implies thAt A request for OS
service mAde by A user process must move down from the highest numbered lAyer
to the lowest numbered lAyer before the required ACtion is performed by the bAre
mAChine. This feAture leAds to high overheAd
The second problem concerns diffificulties in developing A lAyered design.
Since A lAyer cAn ACCess only the immediAtely lower lAyer, All feAtures And fACilities
needed by it must be AVAilAble in lower lAyers.
The third problem concerns strAtifificAtion of OS functionAlities. StrAtifificAtion
occurs becAuse eACh functionAlity hAs to be divided into pArts thAt fifit into
different lAyers of A lAyered OS. These pArts must use interfACes between the
vArious lAyers to communicAte with one Another.

VIRTUAL MACHINE OPERATING SYSTEMS

The VM OS creAtes severAl virtuAl
mAChines. EACh virtuAl mAChine is AllocAted to one user, who cAn use Any OS of his
own choice on the virtuAl mAChine And run his progrAms under this OS. This wAy
users of the computer system cAn use different operAting systems At the sAme time.
We cAll eACh of these operAting systems A guest OS And cAll the virtuAl mAChine
OS the host OS. The computer used by the VM OS is cAlled the host mAChine.
BecAuse of the identicAl
Architectures of the virtuAl And host mAChines, no semAntic gAp exists between
them, so operAtion of A VirtuAl mAChine does not introduce Any performAnce loss
The Absence of A softwAre lAyer
between the host mAChine And guest OS ensures effificient use of the host mAChine.
INTERRUPTS IN VM OS:
Some of the interrupts would Arise in its own
domAin, e.g., An I/O interrupt from A device included in its own virtuAl mAChine,
while others would Arise in the domAins of other guest OSs. The VM OS cAn
ArrAnge to get control when An interrupt occurs, fifind the guest OS whose
domAin
the interrupt belongs to, And “schedule” thAt guest OS to hAndle it. However,
this ArrAngement incurs high overheAd becAuse of two context switch operAtions
—the fifirst context switch pAsses control to the VM OS, And the second pAsses
control to the correct guest OS. Hence the VM OS mAy use An ArrAngement in
which the guest OS in operAtion would be invoked directly by interrupts Arising
in its own domAin.
It is implemented As follows: While pAssing control to A guest operAting
system, the VM OS replACes its own interrupt vectors (see Section 2.2.5) by those
defifined in the guest OS. This ACtion ensures thAt An interrupt would switch the
CPU to An interrupt servicing routine of the guest OS. If the guest OS fifinds thAt
the interrupt did not occur in its own domAin, it pAsses control to the VM OS
by mAking A speciAl system cAll “invoke VM OS.” The VM OS now ArrAnges to
pAss the interrupt to the AppropriAte guest OS. When A lArge number of virtuAl
mAChines exists, interrupt processing cAn cAuse excessive shufflfling between virtuAl
mAChines, hence the VM OS mAy not immediAtely ACtivAte the guest OS in whose
domAin An interrupt occurred—it mAy simply note occurrence of interrupts thAt
occurred in the domAin of A guest OS And provide this informAtion to the guest
OS the next time it is “scheduled.”
VirtuAlizAtion is the process of mApping the interfACes And resources of A

virtuAl mAChine into the interfACes And resources of the host mAChine. Full virtu
AlizAtion would imply thAt the host mAChine And A VirtuAl mAChine hAVe identicAl
cApAbilities, hence An OS cAn operAte identicAlly while running on A bAre mAChine
And on A VirtuAl mAChine supported by A VM OS.
PArAVirtuAlizAtion
replACes A nonvirtuAlizAble instruction, i.e., An instruction thAt cAnnot be mAde
AVAilAble in A VM, by eAsily virtuAlized instructions.