24

# Operating System Structures

➔ The operating system is a complicated piece of software. The size of the operating system is very
large and it is not wise to keep the full operating system in the memory all the time because very
little space would be left for other application programs, due to the limited size of the memory.
➔ Therefore the operating system is divided into two parts. One consists of very essential routines
which are required very often and almost all the time and the other consists of routines which
are required sometimes, but not always. The vital portion is called the kernel of the operating
system. This is the innermost layer of the operating system close to the hardware and control
it. It is the heart of the operating system. To find out the memory overhead the operating
system puts on the system, determine the kernel size. All the other routines are loaded from the
disk to the memory when needed. This saves the use of memory but then you lose the time it
takes to load the required routines when necessary. This is the trade-off which decides the size
of the kernel and also the design of the operating system.

Fig: Kernel of Operating System

➔ Depending upon the size and functionality included in the kernel and the organization of
different components within the operating system, there are four broad approaches for
designing an operating system:
➔ Monolithic Operating System
➔ Layered Operating System
➔ Microkernel Operating System
➔ Exokernel Operating System
 25

# Monolithic Operating System

➔ This is the oldest of all the approaches used to design the operating system. The modules of the
operating system are not organized in a well-defined manner and a module can call any other
module without any major restriction. However, the operating system does not distinguish
between the system mode and user mode while executing an application program. An application
program is run in the user mode. When it makes a system call, the operating system traps the
system call, and executes it in the system mode. Once the execution of the system call is
complete, the execution of the application program resumes in the user mode.
➔ Since there are very few interfaces between the application programs and the underlying
hardware. Monolithic Operating System delivers a good performance. But on the other hand, it
is extremely difficult to enhance or maintain such an operating system and modifications to one
module of the operating system can adversely affect other components modules. Examples of
such systems are early personal computer operating systems like MS-DOS, modern Linux OS.

Fig: Monolithic Operating System

# Layered Operating System

➔ The problems encountered while maintaining or enhancing Monolithic Operating Systems
prompted the designers of the operating systems to follow a much more systematic approach.
➔ Layered Operating Systems proved to be the next logical step.As the name suggests, the modules
of the operating systems are divided into several layers stacked one above the other, thus
forming a hierarchical structure. The lowest layer Layer 0 interacts with the underlying
 26

hardware and the topmost layer Layer N provides an interface to the application programs/
users. The below figure depicts the architecture of a layered operating system.

Fig: Layered Operating System

➔ Communication happens only between adjacent layers. Bypassing of layers is now allowed. That
is a layer say layer M in this structure can request for services only from a layer immediately
below it layer M-1. Also it can provide services only to the layer immediately above it layer M+1.
a layer only needs to know what services are offered by the layer below it and not how the
services are offered. Essentially, the implementation of a service is separated from its interface.
Example, a layer providing Processor Scheduling may internally use the FCFS algorithm or SJF
algorithm to provide necessary service. But a layer requiring the services from this layer is
completely unaware of such details. Moreover, the scheduling algorithm can be easily changed to
say Round Robin Algorithm without disturbing the layers above it. This is known as
Encapsulation. A great advantage of encapsulation is that implementation of a layer can be
easily changed without affecting the other layers, provided the interface remains the same.
Layering thus makes it easier to build, maintain and enhance an operating system. The OS can
be debugged starting at the zeroth layer, adding one layer at a time until the entire system
works correctly. In this approach, pinpointing the location of the error is easier.
➔ On the other hand, this layered approach also makes these Operating Systems somewhat less
efficient compared to Monolithic Operating Systems, as all requests pass through multiple layers
of software before they reach the hardware. For example, if a program needs to read data from
a file, it will execute a system calL.The system-call interface layer will trap this call and it will
 27

call the fi1e system management layer with arguments like file name and the desired operation,
The file system management layer in tum will call memory management layer passing a pointer
to the memory location corresponding to the file. The memory management layer will use the
services of the processor scheduler layer that will finally allocate the processor to carry out the
desired operation. As a result, the overheads incurred at each layer may make the overall
operation slower
➔ Additionally, at times it may not be possible to decide.;1f.l'Ilasthould go in a panicular layer.
There may be overlapping functionalities, or layers that focus on too many or too little features.
Thus it may happen that some of the layers do not do much work and others are heavily loaded
thus creating performance bottlenecks.
➔ Examples of Layered Operating Systems are VAX/VMS and UNIX

# Microkernel Operating System

➔ Layered Operating Systems are better organized and more systematic in terms of their design
and operation. However, generally they have proven to be less efficient. Moreover, as the
designers of the Operating Systems started adding more and more features, the kernel became
'too heavy' and unmanageable. These obstacles gave birth to a totally new approach for
designing Operating Systems-the l\.licrokemel approach. Microkernel has become a real
buzzword in the world of Operating Systems today with more and more Operating Systems
subscribing to this approach.
➔ The basic concept of a Microkernel Operating Systems is very easy to understand. In this
approach, the kernel provides only the most essential Operating System functions like process
management, communication primitives and low-level memory management. System programs or
user level programs, implemented outside the kernel, provide the remaining Operating System
services. These programs are known as servers. As a result, the size of the kernel reduces
dramatically, making it a Microkemel. The application programs and various servers
communicate with each other using messages that pass through the Microkernel, The
Microkernel validates the messages, passes them between the various modules of the Operating
System and permits access to the hardware. Figure below illustrates the working of a
Microkernel Operating System. The Mach Operating System developed at Carnegie Mellon
University in the I980s was the first Operating System built using the Microkernel approach.
Andrew Tanenbaum's Minix is another example of a Microkernel Operating System.
 28

Fig. Microkernel Operating System

➔ There are many advantages of using the Microkernel approach. This approach makes the
system very robust. If there is some problem with a particular server, then the service can be
reconfigured and restarted without having to restart the entire operating system. The system
is also very extensible that is a new service can be easily added simply by adding a new server
without impacting the other parts of the system. As a kerne;l and servers are separated fro,m
each other, it is also possible to build different operating systems catering to a particular
environment using a single microkernel. For example, a number of operating systems like Mac
OS X, Tr64 UNIX and some favours of Linux are implemented with a Mach Microkernel.
Finally, as only the Microkernel interacts with the underlying hardware, porting the operating
system to various platforms is easier.
➔ Despite these features, the first generation Microkernels were somewhat inefficient and slower
due to the overheads incurred by the extensive message passing between application programs
and various servers. Additionally, despite the name, the size of many Microkernels was not very
small thus occupying a considerable portion of memory. However, subsequent generations of
Microkernels have tried to address this problem in various ways and as a result, latest
Microkernels like L4 and QNX are much smaller in size and are yet very efficient.
 29

# Linux
➔ Linux does not use a microkernel approach.
➔ Linux is structured as a collection of modules, a number of which can be automatically loaded
and unloaded on demand. These relatively independent blocks are referred to as loadable
modules. A module is an object file whose code can be linked to and unlinked from the kernel at
runtime. A module implements some specific function, such as a file system, a device driver, or
some other feature of the kernel’s upper layer. A module does not execute as its own process or
thread, although it can create kernel threads for various purposes as necessary. Rather, a
module is executed in kernel mode on behalf of the current process. Thus, although Linux may be
considered monolithic, its modular structure overcomes some of the difficulties in developing and
evolving the kernel.
➔ The Linux loadable modules have two important characteristics:
➔ Dynamic linking: A kernel module can be loaded and linked into the kernel while the kernel is
already in memory and executing. A module can also be unlinked and removed from memory at
any time.
➔ Stackable modules: The modules are arranged in a hierarchy. Individual modules serve as
libraries when they are referenced by client modules higher up in the hierarchy, and as clients
when they reference modules further down.
➔ Dynamic linking facilitates configuration and saves kernel memory. In Linux, a user program or
user can explicitly load and unload kernel modules using the insmod and rmmod commands. The
kernel itself monitors the need for particular functions and can load and unload modules as
needed. With stackable modules, dependencies between modules can be defined. This has two
benefits:
➔ 1. Code common to a set of similar modules (e.g., drivers for similar hardware) can be moved
into a single module, reducing replication.
➔ 2. The kernel can make sure that needed modules are present, refraining from unloading a
module on which other running modules depend, and loading any additional required modules
when a new module is loaded.
➔ Below Figure is an example that illustrates the structures used by Linux to manage modules. The
figure shows the list of kernel modules after only two modules have been loaded: FAT and VFAT.
Each module is defined by two tables: the module table and the symbol table (kernel_symbol).
The module table includes the following elements:
➔ *next: Pointer to the following module. All modules are organized into a linked list. The list
begins with a pseudo module.
➔ *name: Pointer to module name
➔ size: Module size in memory pages
 30

➔ usecount: Module usage counter. The counter is incremented when an operation involving the
module’s functions is started and decremented when the operation terminates.
➔ flags: Module flags
➔ nsyms: Number of exported symbols
➔ ndeps: Number of referenced modules
➔ *syms: Pointer to this module’s symbol table
➔ *deps: Pointer to list of modules that are referenced by this module
➔ *refs: Pointer to list of modules that use this module
➔ The symbol table lists symbols that are defined in this module and used elsewhere.

# Kernel Components
➔ Below Figure shows the main components of the Linux kernel as implemented on an IA-64
architecture (e.g., Intel Itanium). The figure shows several processes running on top of the
kernel. Each box indicates a separate process, while each squiggly line with an arrowhead
represents a thread of execution. The kernel itself consists of an interacting collection of
components, with arrows indicating the main interactions. The underlying hardware is also
depicted as a set of components with arrows indicating which kernel components use or control
which hardware components. All of the kernel components, of course, execute on the processor
but, for simplicity, these relationships are not shown. Briefly, the principal kernel components
are the following:
➔ Signals: The kernel uses signals to call into a process. For example, signals are used to notify a
process of certain faults, such as division by zero.
➔ System calls: The system call is the means by which a process requests a specific kernel service.
There are several hundred system calls, which can be roughly grouped into six categories: file
system, process, scheduling, interprocess communication, socket (networking), and
miscellaneous.
➔ Processes and scheduler: tes, manage, and schedule processes.
➔ Virtual memory: Allocates and manages virtual memory for processes.
➔ File systems: Provide a global, hierarchical namespace for files, directories, and other
file-related objects and provide file system functions.
➔ Network protocols: Support the Sockets interface to users for the TCP/IP protocol suite.
➔ Character device drivers: Manage devices that require the kernel to send or receive data one
byte at a time, such as terminals, modems, and printers.
➔ Block device drivers: Manage devices that read and write data in blocks, such as various forms
of secondary memory (magnetic disks, CD-ROMs, etc.).
 31

➔ Network device drivers: Manage network interface cards and communications ports that
connect to network devices, such as bridges and routers.
➔ Traps and faults: Handle traps and faults generated by the processor, such as a memory fault.
➔ Physical memory: Manages the pool of page frames in real memory and allocates pages for
virtual memory.
➔ Interrupts: Handle interrupts from peripheral devices

➔ Some Linux Signals

➔ SIGHUP Terminal hangup
➔ SIGCONT Continue
➔ SIGQUIT Keyboard quit
➔ SIGTSTP Keyboard stop
➔ SIGTRAP Trace trap
➔ SIGTTOU Terminal write
➔ SIGBUS Bus error
➔ SIGXCPU CPU limit exceeded
➔ SIGKILL Kill signal
➔ SIGVTALRM Virtual alarm clock
➔ SIGSEGV Segmentation violation
➔ SIGWINCH Window size unchanged
➔ SIGPIPT Broken pipe
➔ SIGPWR Power failure
➔ SIGTERM Termination
➔ SIGRTMIN First real-time signal
➔ SIGCHLD Child status unchanged
➔ SIGRTMAX Last real-time signal

➔ Some Linux System Calls

➔ File System Related
close Close a file descriptor.
link Make a new name for a file.
open Open and possibly create a file or device.
read Read from file descriptor.
write Write to file descriptor.
➔ Process Related
 32

execve Execute program.

exit Terminate the calling process.
getpid Get process identification.
setuid Set user identity of the current process.
ptrace Provide a means by which a parent process may observe and
control the execution of another process, and examine and
change its core image and registers.

➔ Scheduling Related

sched_getparam Set the scheduling parameters associated with the scheduling

policy for the process identified by pid.

sched_get_priority_max Return the maximum priority value that can be used with the
scheduling algorithm identified by policy.

sched_setscheduler Set both the scheduling policy (e.g., FIFO) and the
associated parameters for the process pid.

sched_rr_get_interval Write into the timespec structure pointed to by the

parameter tp the round robin time quantum for the process
pid.

sched_yield A process can relinquish the processor voluntarily without

blocking via this system call. The process will then be moved
to the end of the queue for its static priority and a new
process gets to run.
 33

➔ IPC Related

msgrcv A message buffer structure is allocated to receive a message. The system

call then reads a message from the message queue specified by msqid into
the newly created message buffer.

semctl Perform the control operation specified by cmd on the semaphore set semid.

semop Perform operations on selected members of the semaphore set semid.

shmat Attach the shared memory segment identified by semid to the data
segment of the calling process.

shmctl Allow the user to receive information on a shared memory segment; set the
owner, group, and permissions of a shared memory segment; or destroy a
segment.

➔ Socket Related

bind Assign the local IP address and port for a socket. Return 0 for success
and -1 for error.

connect Establish a connection between the given socket and the remote socket
associated with sockaddr.

gethostname Return local host name.

send Send the bytes contained in buffer pointed to by *msg over the given socket.
 34

setsockopt Set the options on a socket