Unit-2

Operating System Structure

Kernel
Kernel is central component of an operating system that manages operations of computer and
hardware. It basically manages operations of memory and CPU time. It is core component of an
operating system. Kernel acts as a bridge between applications and data processing performed at
hardware level using inter-process communication and system calls.
Kernel loads first into memory when an operating system is loaded and remains into memory until
operating system is shut down again. It is responsible for various tasks such as disk management,
task management, and memory management.
It decides which process should be allocated to processor to execute and which process should be
kept in main memory to execute. It basically acts as an interface between user applications and
hardware. The major aim of kernel is to manage communication between software i.e. user-level
applications and hardware i.e., CPU and disk memory.
Objectives of kernel
• To establish communication between user level application and hardware.
• To decide state of incoming processes.
• To control disk management.
• To control memory management.
• To control task management

Different types of kernel are

1. Monolithic kernel
2. Microkernel
3. Exokernel
4. Nanokernel
A system as large and complex as a modern operating system must be engineered carefully if it is
to function properly and be modified easily. A common approach is to partition the task into small
components, or modules, rather than have one monolithic system. Each of these modules should
be a well-defined portion of the system with carefully defined inputs, outputs and functions.

Monolithic kernel
In the monolithic approach the entire operating system runs as a single program in kernel mode.
The operating system is written as a collection of procedures, linked together into a single large
executable binary program. When this technique is used, each procedure in the system is free to
call any other one, if the latter provides some useful computation that the former needs. Being able
to call any procedure you want is very efficient, but having thousands of procedures that can call

1
each other without restriction may also lead to a system that is unwieldy and difficult to understand.
Also, a crash in any of these procedures will take down the entire operating system.
To construct the actual object program of the operating system when this approach is used, one
first compiles all the individual procedures (or the files containing the procedures) and then binds
them all together into a single executable file using the system linker. In terms of information
hiding, there is essentially none—every procedure is visible to every other procedure (as opposed
to a structure containing modules or packages, in which much of the information is hidden away
inside modules, and only the officially designated entry points can be called from outside the
module).
Even in monolithic systems, however, it is possible to have some structure. The services (system
calls) provided by the operating system are requested by putting the parameters in a well-defined
place (e.g., on the stack) and then executing a trap instruction. This instruction switches the
machine from user mode to kernel mode and transfers control to the operating system. The
operating system then fetches the parameters and determines which system call is to be carried out.
After that, it indexes into a table that contains in slot k a pointer to the procedure that carries out
system call k.
This organization suggests a basic structure for the operating system:
1. A main program that invokes the requested service procedure.
2. A set of service procedures that carry out the system calls.
3. A set of utility procedures that help the service procedures.
In this model, for each system call there is one service procedure that takes care of it and executes
it. The utility procedures do things that are needed by several service procedures, such as fetching
data from user programs. This division of the procedures into three layers is shown in Figure.
In addition to the core operating system that is loaded when the computer is booted, many operating
systems support loadable extensions, such as I/O device drivers and file systems. These
components are loaded on demand. In UNIX they are called shared libraries. In Windows they
are called DLLs (Dynamic-Link Libraries). They have file extension .dll and the
C:\Windows\system32 directory on Windows systems has well over 1000 of them.

Main
procedure

Service
procedures

Utility
procedures

Fig: A simple structuring model for a monolithic system.

2
Advantages:

• It provides CPU scheduling, memory scheduling, file management through System

calls only.
• Execution of the process is fast because there is no separate memory space for user and
kernel.
Disadvantages:

• If any service fails, then it leads to system failure.

• If new services are to be added then the entire Operating System needs to be modified.

Microkernel
Microkernel is one of the classifications of the kernel. Being a kernel, it manages all system
resources. But in a microkernel, the user services and kernel services are implemented in
different address space. The user services are kept in user address space, and kernel services are
kept under kernel address space, thus also reduces the size of kernel and size of operating system
as well.

It provides minimal services of process and memory management. The communication between
client program/application and services running in user address space is established through
message passing, reducing the speed of execution microkernel. The Operating System remains
unaffected as user services and kernel services are isolated so if any user service fails it does not
affect kernel service. Thus, it adds to one of the advantages in a microkernel. It is
easily extendable i.e. if any new services are to be added they are added to user address space and
hence requires no modification in kernel space. It is also portable, secure and reliable.

3
Microkernel is solely responsible for the most important services of operating system they are
named as follows:
• Inter process-Communication
• Memory Management
• CPU-Scheduling
Advantages:

• If new services are to be added then it can be easily added.

Disadvantages:

• Since we are using User Space and Kernel Space separately, so the communication
between these can reduce the overall execution time.
Exokernel
Rather than cloning the actual machine, as is done with virtual machines, another strategy is
partitioning it, in other words, giving each user a subset of the resources. Thus one virtual machine
might get disk blocks 0 to 1023, the next one might get blocks 1024 to 2047, and so on.
At the bottom layer, running in kernel mode, is a program called the exokernel (Engler et al., 1995).
Its job is to allocate resources to virtual machines and then check attempts to use them to make
sure no machine is trying to use somebody else’s resources. Each user-level virtual machine can
run its own operating system, as on VM/370 and the Pentium virtual 8086s, except that each one
is restricted to using only the resources it has asked for and been allocated.
The advantage of the exokernel scheme is that it saves a layer of mapping. In the other designs,
each virtual machine thinks it has its own disk, with blocks running from 0 to some maximum, so
the virtual machine monitor must maintain tables to remap disk addresses (and all other resources).
With the exokernel, this remapping is not needed. The exokernel need only keep track of which
virtual machine has been assigned which resource. This method still has the advantage of
separating the multiprogramming (in the exokernel) from the user operating system code (in user
space), but with less overhead, since all the exokernel has to do is keep the virtual machines out of
each other’s hair.

Nanokernel
In a Nanokrnel, as the name suggests, the whole code of the kernel is very small i.e. the code
executing in the privileged mode of the hardware is very small. The term nanokernel is used to
describe a kernel that supports a nanosecond clock resolution.
Advantages:

• It offers hardware abstractions without system services.

Disadvantages:

4
 • It is quite same as Micro kernel hence it is less used.

Layered System
The system had six layers, as shown in Figure. Layer 0 dealt with allocation of the processor,
switching between processes when interrupts occurred or timers expired. Above layer 0, the system
consisted of sequential processes, each of which could be programmed without having to worry
about the fact that multiple processes were running on a single processor. In other words, layer 0
provided the basic multiprogramming of the CPU.
Layer Function
5 The operator
4 User programs
3 Input/output management
2 Operator-process communication
1 Memory and drum management
0 Processor allocation and
multiprogramming
Fig: Structure of the Operating System
Layer 1 did the memory management. It allocated space for processes in main memory and on a
512K word drum used for holding parts of processes (pages) for which there was no room in main
memory. Above layer 1, processes did not have to worry about whether they were in memory or
on the drum; the layer 1 software took care of making sure pages were brought into memory at the
moment they were needed and removed when they were not needed.
Layer 2 handled communication between each process and the operator console (that is, the user).
On top of this layer each process effectively had its own operator console. Layer 3 took care of
managing the I/O devices and buffering the information streams to and from them. Above layer 3
each process could deal with abstract I/O devices with nice properties, instead of real devices with
many peculiarities. Layer 4 was where the user programs were found. They did not have to worry
about process, memory, console, or I/O management. The system operator process was located in
layer 5.

Client-Server Model
A slight variation of the microkernel idea is to distinguish two classes of processes, the servers,
each of which provides some service, and the clients, which use these services. This model is
known as the client-server model. Often the lowest layer is a microkernel, but that is not required.
The essence is the presence of client processes and server processes.
Communication between clients and servers is often by message passing. To obtain a service, a
client process constructs a message saying what it wants and sends it to the appropriate service.
The service then does the work and sends back the answer. If the client and server happen to run

5
on the same machine, certain optimizations are possible, but conceptually, we are still talking about
message passing here.
An obvious generalization of this idea is to have the clients and servers run on different computers,
connected by a local or wide-area network, as depicted in Figure. Since clients communicate with
servers by sending messages, the clients need not know whether the messages are handled locally
on their own machines, or whether they are sent across a network to servers on a remote machine.
As far as the client is concerned, the same thing happens in both cases: requests are sent and replies
come back. Thus the client-server model is an abstraction that can be used for a single machine or
for a network of machines.
Machine 1 Machine 2 Machine 3 Machine 4

Client File server Process server Terminal server

Kernel Kernel Kernel Kernel

Network

Message from
client to server

Fig: Client-Server Model over a network

Increasingly many systems involve users at their home PCs as clients and large machines elsewhere
running as servers. In fact, much of the Web operates this way. A PC sends a request for a Web
page to the server and the Web page comes back. This is a typical use of the client-server model
in a network.

Virtual Machines
The initial releases of OS/360 were strictly batch systems. Nevertheless, many 360 users wanted
to be able to work interactively at a terminal, so various groups, both inside and outside IBM,
decided to write timesharing systems for it. The official IBM timesharing system, TSS/360, was
delivered late, and when it finally arrived it was so big and slow that few sites converted to it.
VM/370 was based on a smart observation: a timesharing system provides (1) multiprogramming
and (2) an extended machine with a more convenient interface than the bare hardware. The essence
of VM/370 is to completely separate these two functions.
The heart of the system, known as the virtual machine monitor, runs on the bare hardware and
does the multiprogramming, providing not one, but several virtual machines to the next layer up,
as shown in Fig. 1-28. However, unlike all other operating systems, these virtual machines are not
extended machines, with files and other nice features. Instead, they are exact copies of the bare
hardware, including kernel/user mode, I/O, interrupts, and everything else the real machine has.

6
 Fig: The structure of VM/370 with CMS
Because each virtual machine is identical to the true hardware, each one can run any operating
system that will run directly on the bare hardware. Different virtual machines can, and frequently
do, run different operating systems. On the original IBM VM/370 system, some ran OS/360 or one
of the other large batch or transaction-processing operating systems, while others ran a single-user,
interactive system called CMS (Conversational Monitor System) for interactive timesharing
users. The latter was popular with programmers.
When a CMS program executed a system call, the call was trapped to the operating system in its
own virtual machine, not to VM/370, just as it would be were it running on a real machine instead
of a virtual one. CMS then issued the normal hardware I/O instructions for reading its virtual disk
or whatever was needed to carry out the call. These I/O instructions were trapped by VM/370,
which then performed them as part of its simulation of the real hardware. By completely separating
the functions of multiprogramming and providing an extended machine, each of the pieces could
be much simpler, more flexible, and much easier to maintain.

The Shell
The operating system is the code that carries out the system calls. Editors, compilers, assemblers,
linkers, utility programs, and command interpreters definitely are not part of the operating system,
even though they are important and useful. At the risk of confusing things somewhat, in this section
we will look briefly at the UNIX command interpreter, the shell. Although it is not part of the
operating system, it makes heavy use of many operating system features and thus serves as a good
example of how the system calls are used. It is also the main interface between a user sitting at his
terminal and the operating system, unless the user is using a graphical user interface. Many shells
exist, including sh, csh, ksh, and bash. All of them support the functionality described below, which
derives from the original shell (sh).
When any user logs in, a shell is started up. The shell has the terminal as standard input and
standard output. It starts out by typing the prompt, a character such as a dollar sign, which tells
the user that the shell is waiting to accept a command. If the user now types date
for example, the shell creates a child process and runs the date program as the child. While the
child process is running, the shell waits for it to terminate. When the child finishes, the shell types
the prompt again and tries to read the next input line.
The user can specify that standard output be redirected to a file, for example, date >file

7
Similarly, standard input can be redirected, as in sor t <file1 >file2

which invokes the sort program with input taken from file1 and output sent to file2.
The output of one program can be used as the input for another program by connecting them with
a pipe. Thus cat file1 file2 file3 | sort >/dev/lp
invokes the cat program to concatenate three files and send the output to sort to arrange all the
lines in alphabetical order. The output of sort is redirected to the file /dev/lp, typically the printer.
If a user puts an ampersand after a command, the shell does not wait for it to complete. Instead it
just gives a prompt immediately. Consequently, cat file1 file2 file3 | sort >/dev/lp &
starts up the sort as a background job, allowing the user to continue working normally while the
sort is going on. The shell has a number of other interesting features, which we do not have space
to discuss here. Most books on UNIX discuss the shell at some length (e.g., Kernighan and Pike,
1984; Quigley, 2004; Robbins, 2005).
Most personal computers these days use a GUI. In fact, the GUI is just a program running on top
of the operating system, like a shell. In Linux systems, this fact is made obvious because the user
has a choice of (at least) two GUIs: Gnome and KDE or none at all (using a terminal window on
X11). In Windows, it is also possible to replace the standard GUI desktop (Windows Explorer)
with a different program by changing some values in the registry, although few people do this.