The document discusses operating system architectures and provides examples of different architectures. It begins by explaining that operating systems provide a layered architecture that hides the complexity of underlying hardware and manages system resources. It then provides examples of monolithic, layered, and microkernel architectures. Specifically, it summarizes Linux as having a layered kernel and user mode, VMS and Windows as having layered designs with executive and kernel layers, and microkernel designs placing most functionality in user-mode servers.

1. Operating System Architectures
Beuth Hochschule
Summer Term 2014

2. Operating Systems I PT / FF 14
Operating Systems
2
ystem software that manages resourcesystem software that manages resources
S hides complexity of underlying hardwareS hides complexity of underlying hardware
ayered architectureayered architecture
30
Physical devices
Microprogramming
Machine language
Operating system
Compilers Editors
Command
interpreter
Banking
system
Airline
reservation
Web browser Application programs
Hardware
System programs
(C)Tanenbaum2001
Computer Hardware
Operating System
Utilities
Application Programs
End User
Programm
er
OS Designer
(C) Stallings 2004
• Services from the operating system layer
• Program execution in multi-tasking
• Access to I/O devices and files
• Error detection and reaction
• Accounting and authorization

3. Operating Systems I PT / FF 14
Basic Concepts: Process and Virtual Memory
• Unit of execution in operating system is traditionally a process
• Term introduced with MULTICS in the 60‘s to generalize job concept
• Instance of an executed program binary
• Management of multiple running processes is a core operating system task
• Every process contains of executable program, associated data, and state
• Concurrent utilization of resources demands some management
• Operating system must prevent independent processes from mutual code and
data access (isolation)
• Sharing should be explicitely allowable under given security constraints
• Same holds for devices offering resources (storage, communication, ...)
• Operating system should leverage the memory hierarchy transparently ...
3

4. Operating Systems I PT / FF 14
Basic Concepts: Process and Virtual Memory
4
0x00000000 0xFFFFFFFF
0x00000000 0xFFFFFFFF
Physical memory address space
Physical memory address space
Process 1 Process 2 Process 3
•Instructions
•State
•Data
?
Process 1 Process 2 Process 3
Virtual memory
address space
0x00000000 0xFFFFFFFF 0x00000000 0xFFFFFFFF 0x00000000 0xFFFFFFFF
Virtual memory
address space
Virtual memory
address space

5. Operating Systems I PT / FF 14
Basic Concepts: Process and Virtual Memory
• Virtual memory concept in nearly
all existing operating systems
• Programs address memory from a logical point of view,
independent from the amount of physical memory
• Multiple processes can concurrently exist at the same time
if physical memory is abstracted
• Today‘s system can rely on hardware support for this
• Rules
• No user process can touch another user process address space without passing
through the operating system security check
• No user process can touch the memory reserved for the operating system itself
5

6. Operating Systems I PT / FF 14
Operating System Design Goals
• (A) Hide complexity and heterogeneity of the underlying hardware
• Enable the development of portable applications
• (B) Manage system resources
• Time multiplexing: Each process gets to use a resource
• Space multiplexing: Each process gets some part of a resource
• Manage concurrent utilization
• (C) Ensure flexibility, portability and security through layering
• New, fixed or updated services without application modification
• Encapsulation and protection of concurrent users
• Integration of new or modified hardware components
6

7. Operating Systems I PT / FF 14
(A) Hardware Abstraction
• Same machine, different operating systems
• IBM PC: DOS, Linux, NeXTSTEP, Windows, SCO Unix
• DEC VAX: VMS, Ultrix-32, 4.3 BSD UNIX
• Same operating system, different machines
• UNIX
• PC (XENIX 286, APPLE A/UX)
• IBM 360/370 (Amdahl UNIX UTS/580, IBM UNIX AIX/ESA)
• Windows: X86, X64, IA64, ARM, Alpha, PowerPC, MIPS
• Mac OS X : PowerPC, X86, X64
• Linux: ... (27) ...
7

8. Operating Systems I PT / FF 14
(B) Resource Management - Today
• Processor management - Scheduling
• Fairness, non-blocking behavior, priorities
• Memory management
• Virtual versus physical memory, memory hierarchy
• Protection of competing / concurrent programs
• Device management, including storage management
• Hiding of hardware dependencies
• Management of concurrent accesses
• Batch processing
• Definition of an execution order; throughput maximization
8

9. Operating Systems I PT / FF 14
Resource Management - Today
• Fairness
• All [ jobs | processes | executed programs | served users ] should gain
approximately equal and fair resource access
• Differential responsiveness
• Discriminate dynamically among program classes (e.g. amount of I/O)
• Ensure the total set of requirements
• Efficiency
• Maximize throughput + minimize response time +
accommodate as many users as possible
• These criteria conflict !
9
fairness
differential
responsiveness
efficiency

10. Operating Systems I PT / FF 14
(C) Layered Architecture
10
(C) Stallings

11. Operating Systems I PT / FF 14
Layered Architecture
• Old monitor concept translates to separation based on two operation modes:
• Kernel mode
• Privileged mode with strict assumptions about reliability/security of code
• Code is typically memory resident (depends on OS type)
• Management of CPU(s), main memory and I/O, parts of the file system and
networking functionality, all device drivers
• Kernel-mode code shared one view on the available memory
• User mode
• Flexible mode for applications with simpler maintenance and debugging
• Each process in user mode has it‘s own view on the available memory
• User mode processes access kernel mode code via system calls
11

12. Operating Systems I PT / FF 14
Layered Architecture
• System call
• Mode change of the CPU - „trap“
• Parameter transmission possible
via trap parameter, register or stack
count=read(file,buffer, nbytes);
• Monolithically designed system
• Modularized kernel components
compiled as one large binary
• Hardware abstraction and resource
management provided through
system service interface
12
Structuring of Operating SystemsStructuring of Operating Systems
Monolithical systemsMonolithical systems
UnstructuredUnstructured
Supervisor callSupervisor call changeschanges
App App
System services
User Mode
Kernel Mode
34
fromfrom user mode inuser mode intoto
kernel modekernel mode
Hardware
OS
procedures

13. Operating Systems I PT / FF 14
Example: Linux
13
(C) Stallings

14. Operating Systems I PT / FF 14
Layered Architecture
• Layered operating system
• Each layer in the kernel (!) is given access only to lower-level interfaces
14
Layered OSLayered OS
Each layer is given access only to lowerEach layer is given access only to lower--levellevel
interfacesinterfaces
Application
Program
Application
Program
Application
Program
User Mode
System Services
File System
Memory and I/O Device Management
Processor Scheduling
Hardware
User Mode
Kernel Mode

15. Operating Systems I PT / FF 14
Example: VMS and Windows
15
-- a bird’sa bird’s--eye view on architectureseye view on architectures
Program
Development Tools
Layered Products
(Apps)
Layered design for VAX/VMS
operating system OS/2
Windows
POSIX
Environment Subsystems
User
Application
Subsystem DLL
User
Mode
Kernel
Mode
System
& Service
Processes
Windows
46
System-wide data structures
Memory
Management
I/O Subsystem
Process and
time management
System services
Kernel
Record Management Service (RMS)
Executive
Command Language Interpreter (CLI)
Supervisor
Platform-Adaptation Layer (PAL) - Alpha
Support LibrariesUtilities
User
Windows
high-level architecture
Windows
User/GDI
Device
Driver
Executive
Device Drivers Kernel
Hardware Abstraction Layer (HAL)
Mode
VMS and WindowsVMS and Windows
-- a bird’sa bird’s--eye view on architectureseye view on architectures
Program
Development Tools
Layered Products
(Apps)
Layered design for VAX/VMS
operating system OS/2
Windows
POSIX
Environment Subsystems
User
Application
Subsystem DLL
User
Mode
Kernel
Mode
System
& Service
Processes
Windows
46
System-wide data structures
Memory
Management
I/O Subsystem
Process and
time management
System services
Kernel
Record Management Service (RMS)
Executive
Command Language Interpreter (CLI)
Supervisor
Platform-Adaptation Layer (PAL) - Alpha
Support LibrariesUtilities
User
Windows
high-level architecture
Windows
User/GDI
Device
Driver
Executive
Device Drivers Kernel
Hardware Abstraction Layer (HAL)
Mode
• Windows NT design in late 1988 driven by Dave Cutler and colleagues,
former employees of Digital corporation (VMS operating system)
• Original goal was OS/2 replacement, later goal Windows 3.0 replacement
• Many similarities in scheduling, memory management, I/O and driver model
• VMS had four hardware-enforced protection modes -> Intel X86 protection rings
(0)
(1)
(2)
(3)
(0)
(3)

16. Operating Systems I PT / FF 14
Layered Architecture
• Microkernel operating system
• Kernel mode implements only
functionality that cannot be put
into user mode without breaking
functionality [Jochen Liedtke]
• Commonly in kernel mode:
Scheduling, memory
management, and
interprocess communication
(IPC)
• Remaining tasks are covered by
user-mode servers
16
Microkernel OSMicrokernel OS
(Client/server OS)(Client/server OS)
Kernel implements:Kernel implements:
SchedulingScheduling
MemoryMemory
Memory
Server
Client
App
Network
Server
Process
Server
File
Server
Display
Server
38
MemoryMemory
ManagementManagement
InterprocessInterprocess
communicationcommunication
(IPC)(IPC)
UserUser--mode serversmode servers
Microkernel
Hardware
request
reply
User Mode
Kernel Mode

17. Operating Systems I PT / FF 14
Layered Architecture
17
(C) Stallings

18. Operating Systems I PT / FF 14
Application Programming Interface (API)
18
C Library API Windows API POSIX API
Windows
Operating
Systems
Unix
(and Windows)
Operating
Systems
Operating
Systems acting
as Hosted C
Environment
Application
System Calls System CallsSystem Calls
User
Kernel
UNIX OS API
Unix
Operating
System Flavor
(BSD / SYSV)
System Calls

19. Operating Systems I PT / FF 14
API Standardization
• POSIX - Portable Operating System Interface
• Family of standards defined by IEEE, name refers to the original version from 1988
• Intention of offering a unified API across different UNIX-alike products
• Includes specification of shells and tools, since shell scripts are applications
• Focus on source code portability for Unix applications
• Operating systems can be certified for compliance
• Only a few operating systems are fully POSIX certified, including Windows NT 4.0
• Design goal for complying with governmental regulations
• Many design choices in POSIX are driven by the UNIX background (e.g. signals)
19

20. Operating Systems I PT / FF 14
API Standardization
• Standard C Library
• 1989 first version from the American National Standards Institute (ANSI) - C89
• Last version from 2011 (C11), glibc as most common implementation
• Focus on C source code portability for all operating systems
• Portable C programs are easy
• Popular examples: Apache, MySQL, PostgreSQL
• Portable non-C programs typically have a C-based runtime system
• Hadoop (Java), Django (Python)
• Non-portable C programs are possible
• Compiler-specific libraries, operating system - specific system calls
20