Chapter 2
CHAPTER 2
OPERATING SYSTEM STRUCTURE
2.1 Operating-System Services
An Operating System (OS) provides an environment for executing programs and offers various
services to users and programs. These services can be grouped into two categories:
1. Services for the User
2. Services for System Efficiency
a) User Interface (UI)
Allows interaction between user and system.
Types of interfaces:
o GUI (Graphical User Interface): Uses windows, icons, mouse, touch screen
(e.g., Windows, Android).
o CLI (Command Line Interface): User types commands (e.g., MS-DOS, Linux
terminal).
o Touch Interface: Used in mobiles and tablets.
Some OSs support more than one type.
b) Program Execution
OS loads programs into memory and runs them.
Handles normal or abnormal (error) termination.
Manages process creation, execution, and termination.
Chapter 2
c) I/O Operations
Provides standard methods for input/output operations.
Programs use OS functions to read/write data (files, printers, etc.).
Users are not allowed to control devices directly for safety and efficiency.
d) File System Manipulation
OS manages files and directories.
Provides operations like:
o Create, read, write, delete, search, and list files.
Manages permissions and access control.
Supports multiple file systems with different features/performance.
e) Communications
Allows processes to exchange information.
Two main methods:
o Shared Memory: Processes share a memory region.
o Message Passing: Processes send and receive messages.
Communication can be within one system or across a network.
f) Error Detection
OS continuously monitors and handles errors in:
o Hardware: Memory or power failures.
o I/O Devices: Disk, network, or printer errors.
o Programs: Arithmetic overflow, invalid memory access.
Takes corrective action (e.g., terminate process or show error message).
2. Services for System Efficiency
a) Resource Allocation
Manages and allocates system resources:
o CPU time, memory, files, I/O devices.
Uses scheduling algorithms to assign CPU and manage devices efficiently.
b) Logging (Accounting)
Keeps record of:
Chapter 2
o Resource usage by each program/user.
Used for billing, usage statistics, and system optimization.
c) Protection and Security
Ensures controlled access to system resources.
Prevents one process from interfering with another.
Provides user authentication (passwords, etc.).
Protects against unauthorized access and network attacks.
Maintains system stability and data integrity.
2.2 User and Operating-System Interface
The User Interface (UI) allows users to interact with the Operating System (OS).
There are three main types of interfaces:
1. Command-Line Interface (CLI)
2. Graphical User Interface (GUI)
3. Touch-Screen Interface
1. Command-Line Interface (CLI) / Command Interpreter
A text-based interface where users type commands to perform operations.
The command interpreter (also called a shell) reads, interprets, and executes commands.
Examples of Shells (in UNIX/Linux):
Bourne-Again Shell (bash)
C Shell (csh)
Korn Shell (ksh)
Bourne Shell (sh)
Functions:
Executes commands like:
o Create, delete, list, copy, execute files, etc.
Used mainly by system administrators and advanced users.
Command Implementation Methods:
1. Internal Commands:
o The interpreter contains the code for executing the command.
Chapter 2
oExample: del in DOS.
o Interpreter size increases with more built-in commands.
2. External Commands (UNIX Style):
o The interpreter loads a separate system program for each command.
o Example: rm [Link] → loads and runs the rm program.
o New commands can be added easily without changing the shell.
2. Graphical User Interface (GUI)
A user-friendly interface that uses icons, windows, menus, and mouse actions instead of
typing commands.
Based on the desktop metaphor — programs, files, and folders appear as icons
Originated from Xerox PARC (1973) on the Xerox Alto.
Became popular with:
o Apple Macintosh (1980s) – introduced Aqua Interface in macOS.
o Microsoft Windows (since 1.0) – added GUI to MS-DOS.
Features:
Uses mouse or touchpad for navigation.
Clicking icons or menus executes commands.
Visually appealing and easy to use.
GUI in UNIX/Linux:
Traditionally CLI-based, but now has open-source GUIs:
o KDE (K Desktop Environment)
o GNOME (GNU Network Object Model Environment)
Available under open-source licenses.
3. Touch-Screen Interface
Interface used in mobile phones and tablets where users interact through touch gestures.
Features:
Users tap, swipe, and pinch on the screen to perform actions.
Virtual keyboard replaces physical keyboard.
Common in smartphones, tablets, and kiosks.
Examples:
Apple iPhone/iPad Uses Springboard interface.
Android systems Use touch-based GUIs with icons and apps.
Chapter 2
4. Choice of Interface
Depends on:
User preference and experience.
Command-Line Users:
Preferred by system administrators and power users for
o Faster control
o Automation using shell scripts
GUI Users:
Preferred by regular users for:
o Simplicity
o Visual clarity
Examples:
Windows: Mostly GUI, but includes CLI (PowerShell / Command Prompt).
macOS: Provides both Aqua GUI and UNIX-style CLI.
Mobile Devices: Primarily touch-screen interface.
2.3 SYSTEM CALLS
System calls provide an interface between user programs and the operating system (OS).
They allow programs to request services (like file handling, process control, or I/O
operations) from the OS.
Usually available as functions in C or C++.
Low-level operations may require assembly language.
2.3.1 Example: File Copy Program
A simple example of how system calls work is a program that copies data from one file to
another.
One approach is to pass the names of the two files as part of the command— for example,
the UNIX cp command:
cp [Link] [Link]
This command copies the input file [Link] to the output file [Link]. A second approach is
for the program to ask the user for the names.
In an interactive system, this approach will require a sequence of system calls, first to write
a prompting message on the screen and then to read from the keyboard the characters that
define the two files.
On mouse-based and icon-based systems, a menu of file names is usually displayed in a
window. The user can then use the mouse to select the source name, and a window can be
Chapter 2
opened for the destination name to be specified. This sequence requires many I/O system
calls.
The program needs both source (input) and destination (output) file names.
Each name requires I/O system calls to read user input.
The program must open the input file and create/open the output file.
Each step involves separate system calls.
The program must handle possible errors for each system call:
Input file might not exist.
File may be protected (no access permissions).
If errors occur, the program must Display an error message (system call) and terminate
abnormally (another system call).
If an output file with the same name already exists:
The program may abort (system call) Or delete the old file and create a new one (multiple
system calls).
In an interactive system, the program may:
Ask the user whether to replace the existing file or abort. This requires system calls to
display messages and read user input.
2.3.2 Application Programming Interface
Even simple programs may make heavy use of the operating system. Frequently, systems
execute thousands of systems calls per second. Most programmers never see this level of
detail, however. Typically, application developers design programs according to an
application programming interface (API).
The API specifies a set of functions that are available to an application programmer,
including the parameters that are passed to each function and the return values the
programmer can expect.
Chapter 2
Common APIs:
1. Windows API → for Microsoft Windows systems.
2. POSIX API → for UNIX-based systems (UNIX, Linux, macOS).
3. Java API → for programs running on the Java Virtual Machine (JVM).
An application programmer designing a program using an API can expect her program to
compile and run on any system that supports the same API (although, in reality, architectural
differences often make this more difficult than it may appear).
Another important factor in handling system calls is the run-time environment (RTE)—
the full suite of software needed to execute applications written in a given programming
language, including its compilers or interpreters as well as other software, such as libraries
and loaders.
The RTE provides a system-call interface that serves as the link to system calls made
available by the operating system.
The system-call interface intercepts function calls in the API and invokes the necessary
system calls within the operating system.
Typically, a number is associated with each system call, and the system-call interface
maintains a table indexed according to these numbers.
The system call interface then invokes the intended system call in the operating-system
kernel and returns the status of the system call.
Chapter 2
Three general methods are used to pass parameters to the operating system.
1. Using Registers (Simplest Method):
Parameters are passed directly in CPU registers.
2. Using a Memory Block (Table Method):
If parameters exceed the register limit, they are stored in a block or table in memory.
The address of the block is passed in a register to the OS.
Example: Linux
o ≤ 5 parameters → use registers
o >5 parameters → use block method
3. Using the Stack:
Parameters are pushed onto the program’s stack.
The OS pops them off when needed.
Advantage: No limit on number or size of parameters.
Chapter 2
2.3.3 Types of System Calls
System calls can be grouped roughly into six major categories: process control, file management,
device management, information maintenance, communications, and protection.
• Process control
◦ create process, terminate process
◦ load, execute
◦ get process attributes, set process attributes
◦ wait event, signal event
◦ allocate and free memory
• File management
◦ create file, delete file
◦ open, close
◦ read, write, reposition
◦ get file attributes, set file attributes
• Device management
◦ request device, release device
◦ read, write, reposition
◦ get device attributes, set device attributes
◦ logically attach or detach devices
• Information maintenance
◦ get time or date, set time or date
◦ get system data, set system data
◦ get process, file, or device attributes
◦ set process, file, or device attributes
• Communications
◦ create, delete communication connection
◦ send, receive messages
◦ transfer status information
◦ attach or detach remote devices
• Protection
◦ get file permissions
◦ set file permissions
Chapter 2
2.4 System Services
System services, also known as system utilities, provide a convenient environment for program
development and execution.
They can be divided into these categories:
• File management: These programs create, delete, copy, rename, print, list, and generally access
and manipulate files and directories.
• Status information: Some programs simply ask the system for the date,time, amount of available
memory or disk space, number of users, or similar status information. Others are more complex,
providing detailed performance, logging, and debugging information. Typically, these programs
format and print the output to the terminal or other output devices or files or display it in a window
of the GUI. Some systems also support a registry, which is used to store and retrieve configuration
information.
• File modification: Several text editors may be available to create and modify the content of files
stored on disk or other storage devices. There may also be special commands to search contents of
files or perform transformations of the text.
• Programming-language support: Compilers, assemblers, debuggers, and interpreters for
common programming languages (such as C, C++, Java, and Python) are often provided with the
operating system or available as a separate download.
• Program loading and execution: Once a program is assembled or compiled, it must be loaded
into memory to be executed. The system may provide absolute loaders, relocatable loaders, linkage
editors, and overlay loaders. Debugging systems for either higher-level languages or machine
language is needed as well.
• Communications: These programs provide the mechanism for creating virtual connections
among processes, users, and computer systems. They allow users to send messages to one
another’s screens, to browse web pages, to send e-mail messages, to log in remotely, or to transfer
files from one machine to another.
• Background services: All general-purpose systems have methods for launching certain system-
program processes at boot time. Some of these processes terminate after completing their tasks,
while others continue to run until the system is halted.
2.5 Linkers and Loaders
Usually, a program resides on disk as a binary executable file— for example, [Link] or
[Link].
To run on a CPU, the program must be brought into memory and placed in the context of
a process.
Source files are compiled into object files that are designed to be loaded into any physical
memory location, a format known as an relocatable object file .
Next, the linker combines these relocatable object files into a single binary executable
file. During the linking phase, other object files or libraries may be included as well, such
as the standard C or math library (specified with the flag -lm).
Chapter 2
A loader is used to load the binary executable file into memory, where it is eligible to run
on a CPU core.
An activity associated with linking and loading is relocation, which assigns final addresses
to the program parts and adjusts code and data in the program to match those addresses so
that, for example, the code can call library functions and access its variables as it executes.
The loader then loads the specified program into memory using the address space of the
newly created process. (When a GUI interface is used, double-clicking on the icon
associated with the executable file invokes the loader using a similar mechanism.)
The process described thus far assumes that all libraries are linked into the executable file
and loaded into memory.
In reality, most systems allow a program to dynamically link libraries as the program is
loaded. Windows, for instance, supports dynamically linked libraries (DLLs). The benefit
of this approach is that it avoids linking and loading libraries that may end up not being
used into an executable file.
Object files and executable files typically have standard formats that include the compiled
machine code and a symbol table containing metadata about functions and variables that
are referenced in the program.
Chapter 2
2.8 Operating-System Structure
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 single system. Each of these modules should be a well-defined portion of the system, with
carefully defined interfaces and functions.
2.8.1 Monolithic Structure
The simplest structure for organizing an operating system is no structure at all. That is,
place all of the functionality of the kernel into a single, static binary file that runs in a single
address space. This approach—known as a monolithic structure—is a common technique
for designing operating systems.
An example of such limited structuring is the original UNIX operating system, which
consists of two separable parts: the kernel and the system programs.
The kernel is further separated into a series of interfaces and device drivers, which have
been added and expanded over the years as UNIX has evolved.
We can view the traditional UNIX operating system as being layered to some extent, as
shown in Figure 2.12. Everything below the system-call interface and above the physical
hardware is the kernel.
The kernel provides the file system, CPU scheduling, memory management, and other
operating system functions through system calls. Taken in sum, that is an enormous amount
of functionality to be combined into one single address space.
Chapter 2
Advantages:
1. Efficient execution:
o System calls are fast because all functions run in the same address space.
2. Simple design:
o Easier to develop and compile as a single binary.
3. Direct communication:
o Kernel modules can directly call each other without complex mechanisms.
Disadvantages:
1. Difficult to maintain or extend:
o Adding or modifying features can affect the whole system.
2. Less reliable:
o A bug in one module can crash the entire OS.
3. Poor modularity:
o Hard to isolate and test individual components.
4. Security risk:
o Single address space means a faulty or malicious module can compromise the entire
system.
2.8.2 Layered Approach
The monolithic approach is often known as a tightly coupled system because changes to
one part of the system can have wide-ranging effects on other parts.
Alternatively, we could design a loosely coupled system. Such a system is divided into
separate, smaller components that have specific and limited functionality. All these
components together comprise the kernel.
The operating system is divided into layers, each built on top of the other.
Layer 0 (Bottom Layer) → Hardware (CPU, memory, I/O devices, etc.)
Top Layer (Layer N) → User interface (commands, applications, etc.)
Each layer acts like an abstract object, which includes:
Data (information the layer manages)
Operations (functions or methods that manipulate that data)
For example:
Layer M can be called by Layer M+1 (higher layer) to perform operations.
Layer M can call Layer M–1 (lower layer) to access hardware-level details.
Advantage:
The layers are selected so that each uses functions (operations) and services of only lower-
level layers.
Easier to design and debug (changes in one layer don’t affect others).
Each layer has a clear, well-defined function.
Chapter 2
Easier to update or replace a single layer.
Layers can control how and when lower-level resources are accessed.
Disadvantage:
Each layer adds some delay because requests must pass through multiple layers.
Communication between layers can make the system slower than a monolithic one.
It is difficult to define proper layers and their exact responsibilities.
Designers must carefully decide what services each layer should provide and how they
interact.
Any modification in a lower layer can affect all upper layers.
2.8.3 Microkernels
As UNIX expanded, the kernel became large and difficult to manage. In the mid-1980s,
researchers at Carnegie Mellon University developed an operating system called Mach that
modularized the kernel using the micro kernel approach.
This method structures the operating system by removing all nonessential components
from the kernel and implementing them as user level programs that reside in separate
address spaces. The result is a smaller kernel.
The main function of the microkernel is to provide communication between the client
program and the various services that are also running in user space.
Communication is provided through message passing, if the client program wishes to
access a file, it must interact with the file server.
The client program and service never interact directly. Rather, they communicate indirectly
by exchanging messages with the microkernel.
Chapter 2
Advantage:
It is easier to extend EX: New services (like device drivers or file systems) can be added
to user space without changing the kernel.
Since most OS services run in user mode, a crash in one service doesn’t crash the entire
system.
The microkernel is small and hardware-independent, making it easier to move (port) the
OS to different hardware platforms.
Disadvantage:
Communication between user-space services and the kernel (via message passing) is
slower than direct function calls.
Managing multiple user processes and inter-process communication (IPC) adds
complexity.
2.8.4 Modules
Perhaps the best current methodology for operating-system design involves using loadable
kernel modules (LKMs). Here, the kernel has a set of core components and can link in
additional services via modules, either at boot time or during runtime.
The idea of the design is for the kernel to provide core services, while other services are
implemented dynamically, as the kernel is running.
Linking servicesdynamicallyispreferabletoaddingnewfeaturesdirectlytothekernel, which
would require recompiling the kernel every time a change was made.
Thus, for example, we might build CPU scheduling and memory management algorithms
directly into the kernel and then add support for different file systems by way of loadable
modules.
Chapter 2
Advantage:
Modules can be added, removed, or updated at runtime without rebooting the system.
Makes it easy to support new hardware or features (e.g., plug-and-play device drivers).
Modules communicate directly (function calls), unlike microkernels that rely on message
passing — resulting in faster performance.
Disadvantage:
Dynamically loaded modules can introduce malicious or unstable code into the kernel
space.
Since modules run in kernel mode, a buggy module can crash the whole system (unlike in
microkernels).
2.8.5 Hybrid Systems
A hybrid kernel combines features of both monolithic kernels and microkernels — aiming to get
the performance of monolithic systems and the modularity and stability of microkernels.
The core kernel runs in kernel mode, handling critical tasks like process scheduling,
memory management, and low-level I/O.
Other services (like device drivers, file systems, or networking) may run in either kernel
space or user space, depending on efficiency and reliability needs.
This mixed design allows a balance between speed and safety.
Examples include:
Windows NT / Windows 10
macOS (XNU kernel)
iOS
Some versions of Linux and Android
[Link] macOS and iOS
Apple’s macOS operating system is designed to run primarily on desktop and laptop
computer systems.
whereas iOS is a mobile operating system designed for the iPhone smartphone and iPad
tablet computer.
The general architecture of these two systems is shown in Figure 2.16. Highlights of the
various layers include the following:
Chapter 2
1. User Experience Layer
This layer defines how users interact with the computer or mobile device. It provides the
graphical user interface (GUI), controls, and overall visual experience.
In macOS:
Uses the Aqua interface
Designed for keyboard, mouse, and trackpad input
Features windows, menus, icons, and the dock (typical desktop interface)
In iOS:
Uses the Springboard interface
Designed for touch-based devices (iPhone, iPad)
Provides icons, home screen, gestures (tap, swipe, pinch, etc.)
[Link] Frameworks Layer
This layer provides libraries and APIs that developers use to build applications for macOS
and iOS.
Frameworks Included:
Cocoa (for macOS)
Used for desktop applications
Supports features like menus, windows, and file management
Cocoa Touch (for iOS)
→Used for mobile apps
→ Supports touch gestures, camera access, accelerometer, and notifications
Programming Languages:
Both frameworks support Objective-C and Swift, Apple’s primary languages for app
development.
[Link] frameworks.
This layer defines frameworks that support graphics and media including, Quick time and
OpenGL
[Link] environment
This environment, also known as Darwin, includes the Mach microkernel and the BSD
UNIX kernel. We will elaborate on Darwin shortly.
Chapter 2
Darwin is a layered system that consists primarily of the Mach microkernel and the
BSD UNIX kernel. Darwin’s structure is shown in Figure 2.17.
Darwin provides two system-call interfaces: Mach system calls (known as traps) and
BSD system calls (which provide POSIX functionality).
The interface to these system calls is a rich set of libraries that includes not only the
standard C library but also libraries that provide networking, security, and
programming language support
[Link] Android
The Android operating system was designed by the Open Handset Alliance (led primarily
by Google) and was developed for Android smartphones and tablet computers.
Android runs on a variety of mobile platforms and is open sourced, partly explaining its
rapid rise in popularity. The structure of Android appears in Figure 2.18.
Android developers can also write Java programs that use the Java native interface—or
JNI—which allows developers to bypass the virtual machine and instead write Java
Chapter 2
programs that can access specific hardware features. Programs written using JNI are
generally not portable from one hardware device to another.
The set of native libraries available for Android applications includes frameworks for
developing web browsers (webkit), database support (SQLite), and network support, such
as secure sockets (SSLs).
2.9 Building and Booting an Operating System
2.9.1 Operating-System Generation
Most commonly, a computer system, when purchased, has an operating system already
installed. For example, you may purchase a new laptop with Windows or macOS
preinstalled.
But suppose you wish to replace the preinstalled operating system or add additional
operating systems. Or suppose you purchase a computer without an operating system. In
these latter situations, you have a few options for placing the appropriate operating system
on the computer and configuring it for use.
If you are generating (or building) an operating system from scratch, you must follow these steps:
1. Write the operating system source code (or obtain previously written source code).
2. Configure the operating system for the system on which it will run.
3. Compile the operating system.
4. Install the operating system.
5. Boot the computer and its new operating system.
2.9.2 System Boot
After an operating system is generated, it must be made available for use by the hardware.
The process of starting a computer by loading the kernel is known as booting the system. On most
systems, the boot process proceeds as follows:
1.A small piece of code known as the bootstrap program or boot loader locates the kernel.
2. The kernel is loaded into memory and started.
3. The kernel initializes hardware.
4. The root file system is mounted.
Chapter 2
VTU PREVIOUS YEAR QUESTIONS
1)Explain the Operating system services with respect to programs and users with neat diagram.
2)What are system calls. List and explain different types of system calls.
3) Describe about Operating Systems structures in detail.
4)Explain about system calls with an example of handling user applications invoking the open()
system call.
5)Analyze Modular kernel approach with layered approach with a neat diagram.
6) Explain the complete process of linking and loading with a neat diagram.
7) Explain the architecture of a monolithic operating system with a neat diagram.