1

OPERATING SYSTEM CONCEPTS

Operating Systems
Operating System Concepts

▪ Processes
▪ Address spaces
▪ Files
▪ Input/Output
▪ Protection
▪ The shell
Processes 3

▪ Program in execution
▪ Lives in address space
o a list of memory locations from 0 to some maximum, which the process can read and
write.
▪ Associated with each process is a set of resources e.g.,
o Registers (including the program counter and stack pointer),
o A list of open files
o Outstanding alarms
o Lists of related processes, and
o All the other information needed to run the program.
▪ A process is fundamentally a container that holds all the information needed to
run a program.

Operating Systems
Suspended Processes 4

▪ Multiple processes run on time shared basis and become active/

suspended for some time
▪ A temporarily suspended process must later be restarted in exactly
the same state it had when it was stopped
▪ All process information is stored in a special table during suspension
called a Process table (an array of structures, one for each process
currently in existence)
▪ A suspended process consists of
o Its address space, usually called the core image and
o Its process table entry, which contains the contents of its registers and
many other items needed to restart the process later.

Operating Systems
A Process Tree

• Related processes that are

cooperating to get some job done
often need to communicate with
one another and synchronize their
activities.
• This communication is called
interprocess communication

Process creates child

processes that results in a tree
structure
UID and Process Association 6

▪ Each person authorized to use a system is assigned a UID (User

IDentification) by the system administrator.
▪ Every process started has the UID of the person who started it
for auditing purposes
▪ A child process has the same UID as its parent.
▪ Users can be members of groups, each of which has a GID
(Group IDentification).
▪ One UID, called the superuser (in UNIX), or Administrator (in
Windows), has special power and may override many of the
protection rules.
Operating Systems
Address Spaces 7

▪ When programs run on a computer, they're loaded into the

computer's memory, with each program given its own "address
space." Memory management is essential to ensure programs don't
overlap each other's address spaces.
▪ Memory protection prevents unauthorized access to other
programs' address spaces or the operating system. The CPU uses
special hardware units known as MMUs (Memory Management
Units) and MPUs (Memory Protection Units) to help manage memory
allocation and prevent unauthorized access.
▪ Memory paging comes into play when a program needs more
memory than available. In this case, the operating system allocates
some of the program's data to disk storage to free up memory.
Operating Systems
Files 8

▪ Almost all operating systems support the concept of files.

▪ The OS provides an abstract view of files, hiding the specific
details of storage.
▪ To store and organize files, PC operating systems use
directories.
o Directories group files together in a logical manner.
o The hierarchical structure created by directories and files is known as
a file system.
o File systems can be represented as a tree-like structure.

Operating Systems
File directory 9

▪ the top-level directory is the

root ("/")
▪ It contains subdirectories
like "Documents," "Photos,"
and "Music,“
▪ Each organizing specific
types of files

Operating Systems
 File directory 10

▪ The directory is like a tree, with the root

directory at the top. To access a file,
you need to follow a path from the
root directory, like "/Students/Matty".
▪ Before you can read or write a file, you
need to open it. The operating system
checks if you have permission to
access the file.
▪ If you do, the system gives you a small
number called a "file descriptor" (or "file
handle" in Microsoft Windows) that you
can use to perform operations on the
file.
A File system for university department.

Operating Systems
Mounted File System in UNIX 11

▪ To make it easy to work with removable storage devices, UNIX

allows their file systems to be connected to the main file system.
▪ Before the connection (called a "mount" operation), the file systems
on the hard disk and the CDROM are separate and cannot be
accessed together. In UNIX, you can't use drive names or numbers
in path names.
▪ However, the "mount" system call allows you to attach the
removable media file system to the main file system at any location.
This lets programs access the files on the removable media just like
any other file, without needing to worry about the specific device or
its location.
Operating Systems
 Mounted File System in UNIX 12

• Before the mount call, the root file system, on the hard disk, and a second file
system, on a CDROM, are separate and unrelated.
• The file system on the CD-ROM has been mounted on directory b, thus
allowing access to files /b/x and /b/y.
• First / represents root in UNIX
Operating Systems
Special Files 13

▪ Special files are treated like regular files by the OS, so you can use
the same I/O commands with them.
▪ There are two types of special files: block special files and
character special files.
▪ Block special files represent devices made up of blocks of data, like
hard disks.
▪ Character special files represent devices that take or produce a
stream of characters, like printers or modems.
▪ Special files are typically kept in the /dev directory in UNIX systems.
▪ The names of special files reflect the device they represent, for
example, /dev/lp represents a line printer.

Operating Systems
File, Block or Object Storage 14

There are different ways to store data, and each has its own strengths
and weaknesses.
▪ File storage organizes data as a hierarchy of files within folders. This is
a common way of storing data on computers, where each file can
be accessed by its name and location in the folder structure.
▪ Block storage, on the other hand, divides data into fixed-size chunks
called blocks. These blocks can be accessed directly, which allows
for faster data transfers and more efficient use of storage space.
▪ Object storage is a newer way of storing data, where each object is
given a unique identifier and associated metadata. This makes it
easier to manage large amounts of unstructured data.
Operating Systems
Pipes 15

▪ A pipe is a mechanism by which the output of one process is directed into the
input of another process
▪ From implementation perspective, a pipe is a sort of pseudofile that can be
used to connect two processes

▪ Pipes allow the output of one process to be used as input for another process.
▪ Process A writes to the pipe as though it were an output file, and process B reads
from the pipe as though it were an input file.
▪ In Linux, the pipe command is denoted by '|'.
▪ For example, "cat filename | grep Apple" searches for the word "Apple" in the
contents of "filename".

Operating Systems
I/O, Protection/Shell 16

▪ I/O and file protection:

o read (r), write (w), and execute (x) bits for files
o Assigned to owner, group, everyone else
▪ Shell or command interpreter:
o Key part of UNIX
o Many flavors (Bourne Shell (sh), Bourne Again Shell (bash), C Shell (csh),
Secure Shell (ssh))
▪ UNIX commands:
o "cat" to concatenate files
o "sort" to sort data
o "cat file1 file2 file3 | sort > /dev/lp" to print sorted output
Operating Systems
 17

OPERATING SYSTEM STRUCTURE –

Operating Systems
EXTERNAL INTERFACE
System Calls 18

Operating systems have 2 main functions:

o Providing abstractions to user programs

o Managing the computer’s resources

User programs interact with the operating system through system

calls.
System calls:
o When a program initiates a system call, it triggers a switch to kernel
mode, allowing the OS to perform the necessary operations and return
results to the program
Operating Systems
 System Call Implementation and Calling
▪Operating systems use a table
called the System Call table to
manage system calls.
▪Each system call is associated
with a number that serves as an
index in the table.
▪The table contains the addresses
of the system calls' routines.
▪When a system call is invoked, the
operating system looks up the
corresponding address in the
table and runs the associated
routine.
19
 System Call Implementation and Calling
o Let's consider the "open" system call for opening a file.
➢Assume the system call number for "open" is 5.
➢ The System Call Table would have an entry at index 5 containing the address of the
routine responsible for handling the "open" operation.
o When a program issues an "open" system call, the operating system:
➢ Identifies the system call number (5 for "open").
➢ Looks up the System Call Table at index 5 to get the address of the "open" routine.
➢ Transfers control to the "open" routine, which is a part of the kernel.
➢ The routine executes the necessary code to open the specified file.

20
System Call Implementation and Calling

21
UNIX Read System Call 22

▪ Count=read(fd, buffer, nbytes)

o fd is a file descriptor: A small, non-negative integer that represents an open
file in the current process. Or A unique identifier that specifies the file the
program wants to read from (obtained via a separate system call like open).
➢ When a file is opened, permissions are checked.
➢ If access is allowed, a number (fd) is returned. Then file can be read/written

onbytes: The number of bytes in file or The number of bytes to read from the
file
o Buffer: where read deposits the bytes or where the read data will be stored.
▪ The system call (and the library procedure) return the number of
bytes actually read in count

Operating Systems
System Stack 23

▪ The system stack, also known as the call stack or just the stack,
is a specific region of memory used by the operating system
and programs to manage function calls and temporary data
during program execution. It follows the Last In, First Out (LIFO)
principle.

Operating Systems
 Read System Call 24

1 – 3 Before the Read system call, the calling Count=read(fd, buffer, nbytes)
program first pushes the parameters onto the
stack
Preparation: The user program pushes the
necessary information (parameters) onto the
system stack. In the context of a read system
call, this typically includes:
o File descriptor: A unique identifier that specifies
the file the program wants to read from (obtained
via a separate system call like open).
o Buffer address: The memory location within the
user program where the read data will be stored.
o Number of bytes to read: Indicates the maximum
amount of data the program wants to read from the
file.

Operating Systems
 Read System Call 25

4 – The system-call number is put in a place where Count=read(fd, buffer, nbytes)

the operating system expects it
o System Call Number Placement: The program
stores a unique number that identifies the
specific system call (e.g., 3 for read on Linux) in
a designated register or memory location
accessible by the operating system.

Operating Systems
 Read System Call 26

Count=read(fd, buffer, nbytes)

5 – TRAP instruction to switch from user mode to kernel
mode
o Switching to the Kernel (TRAP): The program
executes a special instruction, often called TRAP
(or similar), which triggers a switch from user
mode (where programs normally operate) to
kernel mode (where the operating system
executes with full privileges).

Operating Systems
 Read System Call 27

6 – Start execution at a fixed address within the kernel Count=read(fd, buffer, nbytes)
o Kernel Entry Point: Execution jumps to a fixed
location within the kernel code, specifically
designed to handle system calls.

Operating Systems
 Read System Call 28

7 – The kernel code that starts following the TRAP Count=read(fd, buffer, nbytes)
examines the system-call number and then dispatches to
the correct system-call handler, usually via a table of
pointers to system-call handlers indexed on system-call
number
o System Call Handler Dispatch: The kernel
examines the system call number you provided
(like number 3 for read) and consults a table to
locate the appropriate handler function for that
specific system call. This table acts like an index,
mapping system call numbers to their
corresponding handler functions.

Operating Systems
 Read System Call 29

▪ 8 – The system-call handler runs Count=read(fd, buffer, nbytes)

o System Call Handler Execution: The identified handler

function, residing within the kernel, now takes over
and performs the actual work required by the system
call. For read, this might involve:
➢ Validating the parameters you provided (file descriptor,
buffer address, etc.).
➢ Accessing the file system to locate the requested file.
➢ Reading the specified amount of data from the file.
➢ Copying the data from the file into the user program's buffer
(the memory location you specified).
➢ Handling any errors that might occur during the process
(e.g., file not found, insufficient permissions).
read(fd, buffer, nbytes).
Operating Systems
 Read System Call 30

Count=read(fd, buffer, nbytes)

▪ 9 – Once it has completed its work,
control may be returned to the user-
space library procedure at the
instruction following the TRAP instruction
o Returning to User Space: Once the handler finishes its
job, control is typically returned back to the user
program, usually at the instruction following the
TRAP instruction that initiated the system call.
▪ 10 – This procedure then returns to the
user program in the usual way
procedure calls return read(fd, buffer, nbytes).
Operating Systems
 Read System Call 31

Count=read(fd, buffer, nbytes)

▪ 11 – The user program cleans up
the stack and increments the SP
o Stack Cleanup: The user program removes the
parameters it pushed onto the stack during
preparation (file descriptor, buffer address, etc.), as
those are no longer needed. It also updates the Stack
Pointer (SP) to reflect the new top of the stack after
this cleanup.

read(fd, buffer, nbytes).

Operating Systems
 Important POSIX System Calls 32

Some of the major POSIX system calls. The return code s is −1 if an error has occurred. The return codes
are as follows: pid is a process id, fd is a file descriptor, n is a byte count, position is an offset within the
file, and seconds is the elapsed time. The parameters are explained in the text.`
The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer
Society for maintaining compatibility between operating systems.
Operating Systems
Accessing and executing System Calls
▪ System calls typically not accessed directly by programs: Its
complex, error-prone, and non-portable & security risks
▪ An API is a set of clearly defined functions, methods, or
protocols that provide a standardized and user-friendly way for Program
programs to interact with an operating system, library, or other API (std lib)
software component
OS
▪ System calls mostly accessed by programs via a high-level Sys Calls
Application Program Interface (API) provide a standardized
Rest of Kernel
and user-friendly way for programs to interact with the
operating system rather than direct system call use
▪ Three most common APIs are :
o Win32 API for Windows,

o POSIX API for POSIX-based systems (including virtually all versions of

UNIX, Linux, and Mac OS X),
o Java API for the Java virtual machine (JVM)
33
Why use APIs Rather than System Calls
Directly?
▪ Portability: APIs provide a level of abstraction that allows programs to run on multiple
platforms without modification, unlike system calls which are platform-dependent

▪ Abstraction: APIs allow programmers to focus on the logic of their programs rather than the
specifics of the underlying system, enhancing productivity and ease of development

▪ Performance: While system calls are faster than APIs due to direct interaction with the
operating system, APIs offer a balance between performance and portability, making them more
versatile for cross-platform development

▪ Functionality: APIs offer a structured way to interact with various components like web-
based systems, databases, software libraries, and operating systems, enabling seamless
communication between different applications and devices
Why use APIs Rather than System Calls
Directly?
code user level code

…
Your Program fd =open(…); Your Program Code
….
API open (…) fopen(…) Standard C library
{…} {…} Code
kernel

sys_open (…)
level

System Calls Kernel Code

{…}
Windows and UNIX API 36

▪ Windows and UNIX have different programming models.

▪ In UNIX, there is almost a one to-one relationship between the
system calls (e.g., read) and the library procedures (e.g., read) used
to invoke the system calls.
o In other words, for each system call, there is roughly one library procedure
that is called to invoke it,
o POSIX has around 100 procedure calls.
➢ A relatively small set
➢ These procedures cover various aspects of interaction between applications and the operating
system, including process management, file and directory operations, interprocess
communication, and more.

Operating Systems
Windows and UNIX API 37

▪ In contrast, Windows decouples library calls from system calls.

▪ Microsoft defines Win32 API to get OS services.
▪ By decoupling API interface from system calls, Microsoft can
change system calls without invalidating existing programs. /
This separation allows Microsoft to modify or change the underlying
system calls without affecting the Win32 API that developers use.
▪ Win32 API has thousands of calls, and many are carried out in
user space.
▪ It's impossible to distinguish between system calls and user-
space library calls in Windows.
Operating Systems
Example of Standard API
▪ Consider the ReadFile() function in the Win32 API — a function for reading from a file

▪ A description of the parameters passed to ReadFile()

o HANDLE file—the file to be read

o LPVOID buffer—a buffer where the data will be read into and written from
o DWORD bytesToRead—the number of bytes to be read into the buffer

o LPDWORD bytesRead—the number of bytes read during the last read

o LPOVERLAPPED ovl—indicates if overlapped I/O is being used

38
Windows Win32 API 39

The Win32 API calls that roughly correspond

to the UNIX calls
Operating Systems
 40

OPERATING SYSTEM STRUCTURE – INSIDE

Operating Systems
INTERFACE
Monolithic Systems
▪ Monolithic design means entire operating system runs as a single
program in kernel mode
▪ It's like a big program made up of thousands of procedures that
can call each other
▪ Efficient approach but can lead to a complex system
▪ A crash in one procedure can bring down the entire operating
system
▪ No information hiding in the monolithic design
▪ Any procedure can access any other procedure's code and data
▪ This can make it difficult to isolate and fix bugs or vulnerabilities.
 Monolithic System 42

The operating system is made up

of three main components:
▪ A main program that receives
requests from users or other
programs.
▪ Service procedures that provide
the requested functionality by
carrying out system calls.
▪ Utility procedures that assist the A simple structuring model for a monolithic system.
service procedures in
completing their tasks.

Operating Systems
Microkernels 43

▪ The microkernel design divides the OS into two parts:

o User services also known as servers, handle high-level tasks such as file systems and network
protocols.
o kernel services, the microkernel, handle core functionalities like process scheduling, interprocess
communication, and memory management.
▪ User services and kernel services operate in separate memory areas to improve reliability
and security: by preventing user-level processes from directly accessing or corrupting
kernel-level data and code.
▪ Communication between user and kernel services happens through message passing:
User-level processes send messages to request services or information from the kernel,
and the kernel responds accordingly.
▪ Microkernel design offers benefits such as easier extension, portability to new hardware,
greater reliability, and improved security.
▪ However, communication between user and kernel services can cause performance
overhead.
Operating Systems
Microkernels 44

Architecture of a typical microkernel.

Operating Systems
 Microkernels 45

▪ Most common desktop operating

systems do not use microkernels,
except for OS X which is based
on the Mach microkernel.
▪ However, microkernels are widely
used in real-time, industrial,
avionics, and military
applications that require high
reliability.
▪ Some well-known microkernels
include Integrity, K42, L4, PikeOS, Structure of the MINIX 3 system.
QNX, Symbian, and MINIX 3.
Operating Systems
Client-Server Model 46

▪ In this variation of the microkernel design, there are two types

of processes: servers and clients.
▪ Servers provide specific services, while clients use those
services.
▪ Communication between clients and servers happens through
message passing.
▪ To obtain a service, a client process creates a message that
specifies what it needs and sends it to the relevant server.
▪ The server then performs the requested task and sends the
result back to the client process.
Operating Systems
Client-Server Model 47

▪ 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
▪ 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.
▪ Increasingly many systems involve users at their home PCs as clients and
large machines elsewhere running as servers.

Operating Systems
Virtual Machines 49

Installed on an existing
Bare-metal” hypervisor
Operating System

Citrix/Xen Server, VMware ESXi and Microsoft Virtual PC, Oracle Virtual Box, VMware
Microsoft Hyper-V. Workstation, Oracle Solaris Zones
Operating Systems
Distinction Between a Type 1 & a Type 2 5050
Hypervisor
Type 1 Hypervisor (Bare-Metal) Type 2 Hypervisor (Hosted)
▪ Installs directly on the physical hardware ▪ Requires a host operating system to be
of the host system. installed first.
▪ It operates without the need for a host ▪ The hypervisor runs as an application
operating system within the host OS and manages
▪ Generally offers better performance ▪ Some performance overhead as it relies
because it has direct access to the on the host operating system for resource
physical hardware resources. management.
▪ Preferred for enterprise-level virtualization, ▪ Commonly used for development,
data centers, and cloud environments testing, and scenarios where
where performance and resource performance is not the primary concern.
efficiency are critical.

Operating Systems
 51

Operating Systems