Operating System (OS) Structure

Lecture 2

Soumyabrata DEV
https://soumyabrata.dev/
Operating Systems Structure

Operating System Architecture

Operating System Structure
} In order to understand any operating system
structure, we must consider its components
and their organisation

} What are the essential components?

} How do they relate to each other?

3
Operating System Structure
} It is important to remember:
} The concepts we study will exist in some form in
every operating system
} But they will be implemented in different ways

} Divisions between components are not always

clearly defined

4
Operating System Components
} Kernel: software containing the core OS
components; it may typically include:

} Memory Manager
} Provides efficient memory allocation and
deallocation of memory

} I/O manager
} Handles input and output requests from and to
hardware devices (through device drivers)

5
Operating System Components
} Inter-process communication (IPC) manager
} Provides communication between different
processes (programs in execution)

} Process Manager (scheduler)

} Handles what is executed when and where
(if more than one CPU)

6
Operating System Components
} An OS kernel may consist of many more
components:
} System service routines
} File System (FS) manager
} Error handling systems
} Accounting systems
} System programs
} And many more

7
Operating System Interface
} Original OS interfaces were very simple and
called Command Line Interface (CLI) or
Command Interpreter (CI)

} This is like the command prompt on windows

and terminal or shell on Mac/Linux

} The user types a command, and the CI

executes it
8
Operating System Interface
} Later systems used a more user-friendly
Graphical User Interface (GUI)

} Based on Desktop idea

} Usually mouse, keyboard, and monitor
} WIMP, (windows, icons, menus, pointing)
} Icons represent files, programs, actions, etc

} Used on almost all systems today

9
Example system

10
OS Structure Issues:
} How are all these components organised?

} What are the entities involved and where do

they exist?

} How do these entities cooperate?

11
Operating System Goals
} When we design an operating system we want
it to be:
} Efficient – (High throughput)
} Interactive
} Robust – (Fault tolerant & reliable)
} Secure
} Scalable
} Extensible
} Portable

12
Monolithic Architecture
} Traditionally, systems were built around
monolithic kernels
} every OS component is contained in the kernel

} any component can directly communicate with

any other (by means of function calls)

} due to this they tend to be highly efficient

(performance)

13
Example : MS DOS
} Written to provide
the most functionality
in the least space

} Not divided into

modules

} Interfaces and levels

of functionality are
not well separated
14
Problems with Monolithic Structure
} Because they are unstructured they are hard
to understand, modify, and maintain

} Susceptible to damage from errant or

malicious code, as all kernel code runs with
unrestricted access to the system

15
Layered Structure
} To try and solve the problems with the
monolithic structure, the layered structure was
developed

} Components are grouped into layers that

perform similar functions

16
Advantages of Layered Structure
} Designing the system as a number of modules
gives the system structure and consistency

} This allows easier debugging, modification and

reuse

17
 each layer is a virtual ma
Layered
a Architecture
higher layer provides a h
} Each layer
communicates only Layer 3
with layers
immediately above Layer 2
and below it
} each layer is a virtual
Layer 1 ←
machine to the layer
above
Layer 0 ←
} a higher layer provides Hardware
a higher-level virtual
machine
18
First Layers-based OS
} Layering was first used in Dijkstra’s THE OS
(1968)

} Each layer “sees” a logical machine provided by

lower layers

19
ayers-based OS
The Layers
Layering was first used in Dijkstra’s THE OS (1968)
layer 4 User Programs
layer 3 I/O Management
layer 2 Console Device (commands), IPC
layer 1 Memory Management
layer 0 CPU Scheduling (multiprogramming)
Hardware

each layer “sees” a logical machine provided by lowe

layer 4 (user space) sees virtual I/O drivers
20
layer 3 sees virtual console
First Layers-based OS
} Each layer “sees” a logical machine provided by
lower layers
} layer 4 (user space) sees virtual I/O drivers
} layer 3 sees virtual console
} layer 2 sees virtual memory
} layer 1 sees virtual processors
} Based on a static set of cooperating processes
} Each process can be tested and verified
independently

21
Problems with layering
} Appropriate definition of layers is difficult
} A layer is implemented using only those
operations provided by lower-lever layers
} A real system structure is often more complex
than the strict hierarchy required by layering

22
Problems with Layering
} Performance issues
} Processes’ requests might pass through many
layers before completion (layer crossing)
} System throughput can be lower than in
monolithic kernels

23
Problems with Layering
} Still susceptible to malicious/errant code if all
layers can have unrestricted access to the
system
} As we will see later, this can only be avoided
through hardware

} As a consequence, (imperfect) layers are often

used for convenience in system design, but any
OS implementation cannot be purely layered

24
Microkernel Architecture
} The microkernel (μ-kernel) architecture was
designed to minimise the services offered by
the kernel

} This was an attempt to keep it small and

scalable

25
Introduction to Microkernel Architecture
} Microkernel architecture is a design approach
for operating systems that aims to minimize
the kernel's size and complexity by moving
most system functions out of the kernel and
into user space.

26
Key Concepts
} Microkernel: The core of the operating system is
minimal, containing only essential functions such as
inter-process communication and hardware
abstraction.
} User Space Servers: Additional functionality
traditionally found in the monolithic kernel, such as
device drivers and file systems, is implemented as
separate user space processes or servers.
} Message Passing: Communication between user space
servers and the microkernel is typically achieved
through message passing.
27
Advantages of Microkernel Architecture
} Modularity: The system is more modular and extensible,
as additional services can be added or removed without
modifying the core kernel.
} Reliability: Isolation of user space servers from the core
kernel improves system stability. If a server crashes, it
can be restarted without affecting the entire system.
} Portability: Microkernels are often more portable across
different hardware platforms because the core kernel is
minimal and hardware-specific code is in user space
servers.
} Security: Enhanced security as user space servers can be
isolated from each other, reducing the attack surface.

28
Examples of Microkernel-based Operating
Systems
} MINIX: Originally created as an educational
tool by Andrew S. Tanenbaum, MINIX is a
microkernel-based operating system.
} QNX: A real-time microkernel operating
system used in embedded systems, automotive
infotainment systems, and more.
} L4: A family of microkernels designed for high
performance and security, used in various
research and commercial systems.

29
Challenges and Considerations
} Performance Overhead: Message passing can
introduce overhead compared to direct function
calls in monolithic kernels.
} Complexity: Developing and maintaining user space
servers can be challenging, potentially offsetting
some of the benefits.
} Design Choices: Microkernel architectures require
careful consideration of which components
should reside in the microkernel and which
should be implemented as user space servers.
30
Microkernel System Structure

Application File Device user

Program System Driver mode

messages messages

Interprocess memory CPU kernel

Communication managment scheduling mode

microkernel

hardware

31
Conclusion
} Microkernel architecture offers a different approach to
operating system design, emphasizing modularity,
reliability, portability, and security. Understanding this
architecture is crucial for gaining insights into modern
operating system design principles.

32
Modules
} Many modern operating systems implement
loadable kernel modules
} Uses object-oriented approach
} Each core component is separate
} Each talks to the others over known interfaces
} Each is loadable as needed within the kernel

} Overall, similar to layers but with more

flexible
} Linux, Solaris, etc
33
Solaris Modular Approach

34
Hybrid Systems
} Most modern operating systems are actually
not one pure model
} Hybrid combines multiple approaches to address
performance, security, usability needs
} Linux and Solaris kernels are in kernel address space,
so they are monolithic, but also modular for
dynamic loading of functionality
} Apple Mac OS X combines a layered approach with a
kernel consisting of Mach microkernel and Berkeley
Software Distribution (BSD) Unix parts, plus I/O kit
and dynamically loadable modules
35
Mac OS X Structure
graphical user interface
Aqua

application environments and services

Java Cocoa Quicktime BSD

kernel environment
BSD

Mach

I/O kit kernel extensions

36
iOS
} Based on Mac OS X
} Cocoa Touch Objective-C API for
developing apps
} Media services layer for graphics, audio, Cocoa Touch

video Media Services

} Core services provides cloud Core Services

computing, databases Core OS

} Core operating system, based on Mac

OS X kernel

37
Android
} Open-Source OS Developed by Open
Handset Alliance (mostly Google)

} Similar stack to IOS

} Based on Linux kernel but modified

} Provides process, memory, device-driver
management
} Adds power management

38
Android
} Runtime environment includes core set of
libraries and Dalvik/ART(2015) virtual
machine

} Apps developed in Java plus Android API

} Java class files compiled to Java bytecode and

then translated to executable and then runs in
Dalvik VM

39
Android Architecture
Applications

Application Framework

Libraries Android runtime

SQLite openGL Core Libraries

surface media
Dalvik
manager framework
virtual machine
webkit libc

Linux kernel

40
 Operating Systems Structure

Operating System and Hardware Features

41
Operating System and Hardware
} An OS is partly dedicated to a specific
hardware architecture

} Good hardware support can greatly simplify its

design

} Hardware features are many times motivated

by OS needs

42
Protected Instructions
} In modern systems some instructions are
typically restricted to the OS (protected or
privileged instructions)

} This is to prevent a faulty or malicious user

program from affecting the whole system

43
Protected Instructions
} Typically, users are not allowed to
} Directly access I/O (disk, printer,. . . )
} Directly manage memory
} Execute CPU halt instructions

} These operations are always handled through

privileged instructions or memory mapping

44
Dual Mode Operation
} The implementation of protected instructions
requires some type of hardware mechanism

} The HW must support - at least - two

operation modes
} kernel mode: access to all the CPU instruction set
} also called monitor/system/privileged mode
} user mode: access restricted to a subset of the
instruction set

45
Dual Mode Operation
} The mode is indicated by a status bit (mode bit)
in a protected processor register
} OS programs & protected instructions executed in
kernel mode
} user programs executed in user mode
} Examples of protection in older and newer
systems:
} MS-DOS (based on Intel 8088): no protection modes
} Windows 2000/XP, OS/2, Linux (based on Intel x86
systems): protection modes

46
Crossing Protection Boundries
} User-mode programs cannot execute
privileged instructions, but they still need
kernel-mode services (I/O operations, memory
management, etc)

} To execute a privileged instruction, a user must

call an OS procedure: system call

47
Crossing Protection Boundries
} A system call causes a trap, which jumps to
the trap handler in the kernel

} When called the trap handler

} users call parameters to determine which system
routine to run
} saves caller’s state: program counter (PC), mode
bit, . . .

48
Crossing Protection Boundries
} After this the hardware must
} Implement caller’s parameters verification (e.g.
memory pointers should only be allowed within
user’s section)
} Return to user-mode when trap system call
finished

} The trap is treated by the hardware as a

software-initiated interrupt

49
Exceptions
} Exception (hardware-initiated interrupt):
basically the same as a trap

} Exceptions are automatically triggered by an

error or a particular situation rather than on
purpose (like in a system call)

50
Exceptions
} Exceptions also transfer control to a handler
within the OS
} system status can be saved on exceptions (memory
dump), so that faulty processes can be later
debugged

} Exceptions decrease performance

} exception conditions could be detected by inserting
extra instructions in the code, but at a high
performance cost
51
Typical Exceptions
} memory access out of user space
} overflow, underflow
} trace traps (debugging)
} illegal use of privileged instructions
} virtual memory (paging): page faults, write to
read-only page

52
Memory Protection
} A memory protection mechanism must
protect
} user programs from each other
} OS (kernel) from user programs

} Simplest scheme is to use base and limit

registers

53
mory protection mechanism must protect
Base and
user programs Limit
from each other Registers
OS (kernel) from user programs
} Base and limit registers are loaded by the OS
lest scheme is to use base and limit registers
before starting the execution of any program
these registers are loaded by the OS before starting the
in ofuser
execution mode in user mode
any program
0
Kernel
256000
Program 1 base register for program 2
300040 300040
Program 2
420940 120900
Program 3 limit register for program 2

} base
base ≤ address≤<address < base
base + limit; + limit;
otherwise otherwise
exception raised
exception raised
54
Memory Protection
} Currently memory protection is more
complex than this

} However, the simple base and limit scheme is

the basis of modern virtual memory when a
strategy called “segmentation” is used

55
I/O Control
} All I/O instructions are privileged
} This is because a program could disrupt the
whole system by issuing illegal I/O instructions

} Two situations must be considered:

} I/O start: handled by system calls
} I/O completion and I/O events: handled by
interrupts

56
I/O Control
} Interrupts are the basis for asynchronous I/O
} I/O devices have small processors that allow them to run
autonomously (i.e. asynchronously with respect to the
CPU)
} I/O devices send interrupt signals when done with an
operation; CPU switches to address corresponding to
interrupt
} an interrupt vector table contains the list of kernel routine
addresses that handle different events

57
CPU Protection
} Apart from protecting memory and I/O, we
must ensure that the OS always maintains
control

} A user program might get stuck into an infinite

loop and never return control to the OS

} Timer: it generates an interrupt after a fixed

or variable amount of execution time
58
CPU Protection
} When an interrupt is generated by the Timer
the OS may choose to treat the interrupt as a
fatal error (and stop program execution) or
allocate more execution time

} note: in time-sharing systems a timer interrupt

is periodically generated after a fixed period of
time (for scheduling a new program)

59
 Thank you!

See you next class!

18 September, Monday, 8am to 9:35am, TB3-202

60