Operating System Structures
Outlook
Operating-System Services p g y
System Call Perspective on Services
O ti S t St t
Operating-System Structure
Operating-System Implementation, Ope at g Syste p e e tat o ,
Generation, and Boot
Operating-System Services
Services can be provided at different levels p
Command interpreter Command interpreter
Command interpreter
Shell: read and interpret control statements
Process creation and
management I/O handling System programs
management, I/O handling,
secondary-storage management, main memory management, file- system access, protection,
t ki System call API
networking, …
Or a mouse-based window and menu system
R y
System Programs
See Windows Systemsteuerung for examples
Ressources
System Call API
E.g. File Open/Read/Write/Close- Interface
Interface
Operating System Service Classes p g y
Services intended for the user
U i t f (CLI b t h GUI)
User interface (CLI, batch, GUI)
Program execution
I/O operations/ p
File-system manipulation
Process communications (shared memory, message passing) Error detection (appropriate OS action for errors debugging
Error detection (appropriate OS action for errors, debugging support)
Services ensuring efficient operation of the system itself
Resource allocation for multiple users or jobs at the same time
e g CPU RAM File storage I/O
e.g. CPU, RAM, File storage, I/O
Accounting for billing or statistics
Protection and security
Essential Components? 5
Process management g
Process = Program in execution
C il d i t t k
Compiler, word-processing program, system task
A process requires resources
CPU time memory files I/O devices
CPU time, memory, files, I/O devices
Processes may run concurrently
Operating system is responsible for
Creating and deleting user and system processes
Creating and deleting user and system processes
Suspending and resuming processes
Providing mechanisms for process synchronization
Providing mechanisms for process communication
Providing mechanisms for deadlock handling
Memory Management y g
Large array of words or bytes
Each word or byte has its own address
Accessible by I/O and CPU
Accessible by I/O and CPU
Many programs in memory requires memory management
management
Operating system is responsible for
Keep who is using what memory parts
Allocating and deallocating memory space to processes
Providing more memory than physically available
7
File Management g
Uniform logical view on information storage
File: Logical storage unit
Organized in directories
Independent of the storage media
Control access permissionsp
Operating system is responsible for
Operating system is responsible for
Creating and deleting files and directories
Primitives for manipulating files and directories
Primitives for manipulating files and directories
Loading or mapping files into RAM
Backing up files on stable storage media Backing up files on stable storage media
Further System Components (1) y p ( )
I/O-System Management / y g
Managing buffering, caching, and spooling General device driver interfaces
General device driver interfaces
Device drivers hiding device peculiarities
Secondary storage management Secondary storage management
Free-space management Storage allocation
Storage allocation
Disk scheduling
9
Further System Components (2) y p ( )
Networking
P id t t k d
Provide access to networked resources
Hide networking hardware by a file access like interface
Protection system
Control access of programs to files, memory, CPU, …Control access of programs to files, memory, CPU, …
System Programs and Utilities y g
File management
Status information
File modification
Programming-language support
Program loading and executing
Program loading and executing
Communications
Utilities often come with OS distribution but do not participate in the OS operation
participate in the OS operation
Browser, word processor, text formatter, spreadsheet, database, plotting, statistical analysis, games, p g, y , g
11
Important Program: Command Interpreter p g p
Possible implementations
Command interpreter contains the command code
Command interpreter loads command programs
Pro and con of loading command programs
Pro and con of loading command programs
Extendibility
Command and interpreter exceeding memory size
Command and interpreter exceeding memory size
Performance
Inconsistent parameter interpretation
Inconsistent parameter interpretation
System Call Perspective on Services
System Calls y
Interface between process and operating system
A il bl f l C C lib i
Available for example as C or C++ library routines
(For certain low level tasks assembly-language instructions might also be useful (e g asm {} pragma in C))
might also be useful (e.g. asm {} pragma in C))
Example : System calls involved in “Copy file A to file B”
Example : System calls involved in Copy file A to file B
Prompt message, read from keyboard
Open A and B
Read from A, write to B
Close A and B
Terminate normally or abnormally
Terminate normally or abnormally
Fact: System calls are frequently (thousands per second)
System Call Interface y
0xfe00 mov #13, d0;
0xfe04 trap 42;
15
Passing Parameters to System Calls g y
Possibilities: registers, memory block g , y
(table), stack
System Calls: Process Control y
end, abort
(core dump debugging, error level)
load, execute ,
(what happens with the calling program?)
create/terminate process
create/terminate process
get/set process attributes (priority maximum execution time) (priority, maximum execution time)
wait time, wait event, signal event
allocate/free memory
dump, trace, single step, profile p g p p (used for debugging)
17
System Calls: File and Device Management y g
Similarity between I/O devices and files
Specific file management system calls
create/delete files and directories
Specific device management system calls
request/release device
request/release device
OS can provide common system calls for files and IO
open, close
read, write, reposition
get/set attributesg /
Consider /dev in Unix systems for example
Further System Calls y
Information maintenance
get/set system dataget/set system data
Time, date, number of users, version, memory space, disk space,
…
( d l)
Communication (message-passing model)
open/close connection
Requires addressing: Process-ID (, Host-ID)
Realized as separate functionality or like file access
Realized as separate functionality or like file access
accept/wait for connection
get hostid or processid
(for a given process name, host name)
(for a given process name, host name)
send/receive messages
Communication (shared-memory model)
Communication (shared memory model)
shared memory create, shared memory attach
controlled removal of the “isolated memory per process” restriction
19
APIs: Hiding the Technical System Call Implementation from Applications
Implementation from Applications
Examples: Win32,
Example ANSI C API, POSIX API
Invoke the system call on behalf of
on behalf of application
Benefits
Portability
Simplification of
Portable Operating System Interface (POSIX) p g y ( )
Gemeinsam von der IEEE und der Open Group für Unix
entwickeltes standardisiertes Application Programming Interface entwickeltes standardisiertes Application Programming Interface (API), das die Schnittstelle zwischen Applikation und dem
Betriebssystem darstellt.
Heutige Standards sind eine Weiterentwicklung aus einem
Heutige Standards sind eine Weiterentwicklung aus einem Projekt im Jahr 1985.
Die meisten Unix-Derivate halten sich mehr oder weniger an die in IEEE1003.1 (1990) und IEEE1003.2 (1992) festgelegten Standards.
IEEE1003.1 (1990) und IEEE1003.2 (1992) festgelegten Standards.
Diese älteren Versionen wurden 2001 durch die überarbeitete
Version IEEE Std 1003.1-2001 der IEEE und Open Group abgelöst.
2004 wurde eine leicht korrigierte Version IEEE Std 1003.1, 20042004 wurde eine leicht korrigierte Version IEEE Std 1003.1, 2004 Edition veröffentlicht.
Die gegenwärtig aktuelle Version ist die Überarbeitung von 2008.
Es besteht die Möglichkeit, ein Produkt zertifizieren zu lassen.
Es besteht die Möglichkeit, ein Produkt zertifizieren zu lassen.
Einige Linux-Distributoren werben inzwischen damit, ein POSIX- konformes Betriebssystem zu vertreiben.
Quelle: Kopie aus http://de.wikipedia.org/wiki/Portable_Operating_System_Interface 21
Portable Operating System Interface (POSIX) p g y ( )
Die Spezifikation der Benutzer- und Software- Schnittstelle des Betriebssystems ist in vier Teile Schnittstelle des Betriebssystems ist in vier Teile
unterteilt, die zusammen den Standard IEEE Std 1003.1- 2008 bilden:
B i D fi i i
Basis-Definitionen
Eine Liste der im Standard benutzten Konventionen, Definitionen, und Konzepte., p
System-Schnittstelle
Die C-Systemaufrufe und dazugehörige Header-Dateien.
K d il i t t d Hilf
Kommandozeileninterpreter und Hilfsprogramme
Eine Liste der Hilfsprogramme und der Kommandozeileninterpreter.p
Erklärungen
Erläuterungen, warum der Standard so ist, wie er ist.
POSIX-Konformität
Betriebssysteme können vollständig oder teilweise POSIX-konform sein – dies hängt davon ab, ob sie die POSIX-Standards gänzlich oder nur zum Teil einhalten. Zertifizierte Produkte werden auf der POSIX Certification Website der IEEE genannt
Produkte werden auf der POSIX-Certification-Website der IEEE genannt.
vollständig POSIX-konform (Folgende Betriebssysteme sind POSIX-kompatibel, sie halten sich an den gesamten Standard)
A/UX AIX BlagOS BSD/OS Darwin (Mac OS X) HP-UX INTEGRITY IRIX LynxOS MINIX OpenVMS penOS QNX A/UX, AIX, BlagOS, BSD/OS, Darwin (Mac OS X), HP UX, INTEGRITY, IRIX, LynxOS, MINIX, OpenVMS, penOS, QNX, RTEMS(POSIX 1003.1-2003 Profile 52), Solarisund OpenSolaris, UnixWare, velOSity, VxWorks
weitgehend POSIX-konform (Diese Betriebssysteme wurden nicht offiziell als POSIX- kompatibel zertifiziert, halten sich aber an den Großteil der Standards)
BeOSund dessen Open-Source-Nachfolger Haiku Nucleus RTOS FreeBSD Linux (die meisten Distributionen siehe BeOSund dessen Open-Source-Nachfolger Haiku, Nucleus RTOS, FreeBSD, Linux (die meisten Distributionen, siehe LSB), NetBSD, OpenBSD, PikeOS (Echtzeitbetriebssystem für eingebettete Systeme mit optionalen PSE51- und PSE52- Partitionen), SkyOS, SuperUX, Syllable, VSTa
konform durch Kompatibilitätserweiterungen (nicht offiziell als POSIX-konform zertifiziert, sind aber weitgehend standardkonform. POSIX-Unterstützung durch eine Art
K tibilität it d i Z i h hi ht üb d K l)
Kompatibilitätserweiterung oder einer Zwischenschicht über dem Kernel)
Die NT-Kernel (XP, Win7, Win8 liegen z.B. in der NT-Linie) von Microsoft Windows bei Nutzung der Microsoft
Windows Services for UNIXUnterstützung von Untermengen wie die Posix Threadswird z. B. durch „Pthreads-w32“
ermöglicht, eCos – POSIX ist Teil der Standard-Distribution und wird von vielen Anwendungen verwendet, Plan 9 from Bell Labs: APE – ANSI/POSIX Environment, Symbian OS mit PIPS (PIPS Is POSIX on Symbian), AmigaOS mit der i l lib
ixemul.library
23 Quelle: Kopie aus http://de.wikipedia.org/wiki/Portable_Operating_System_Interface
Operating-System Structure
System Structure: Simple y p
Example: MS-DOS p
25
System Structure: Monolithic y
Example: original UNIX system structuring p g y g
System Structure: Layered (1) y y ( )
27
System Structure: Layered (2) y y ( )
Advantage
Layers hide details to higher-level layers
Layers hide details to higher level layers
Incremental debugging and verification
Majo diffic lt defining the ight la e f nctions and o de ings
Major difficulty: defining the right layer functions and orderings
Example: Memory management above HD driver
Defining appropriate layers is non-trivial
HD driver should notify CPU scheduler that it is waiting for I/O
HD driver above CPU scheduler
CPU scheduler may want to swap processes between main memory and HD
CPU scheduler above HD driver
Efficiency?
E.g. user calls I/O operation: I/O layer g / p / y memory management layer y g y
System Structure: Microkernel y
Kernel consists of minimal set of services
Process management
Process management
Memory management
Communication facility
N ti l t li d l l
Nonessential components realized as user-level programs
Components always interact via microkernel
Benefits
Extendibility
Portability
Security and reliability
DrawbacksDrawbacks
Performance decreases due to increased system overhead
Experience with Win95, early Win NT, and Win XP
Example systems: Mach Tru64 UNIX QNX
Example systems: Mach, Tru64 UNIX, QNX
29
System Structure: Modules y
OOP techniques to create modular kernel
Modules are well defined by interfaces
Modules interact without message passing
l d
No layered structure
Kernel provides a set of core components
Additional services are linked dynamically
During boot or even run time
Example Systems: Solaris, Linux, Mac OS X
(hybrid approach)
Module vs. Microkernel
Modules
all modules reside in kernel spacep Component A Component B
no message passing via microkernel
better than layering: any module can call any other
Mi k l
Microkernel
components reside in user space
communication via message passing; expensive
Microkernel
Kernel Space
31
System Structure: Virtual Machines y
Non-virtual Machine Virtual Machine
Implementation p
Example: How to realize dual mode in user space?
dual mode in user space?
trap into kernel first
requires some kernel support
Example: Communication
Via file system
Via Software defined network
virtual
of VMs
virtual virtual
user mode
i d
user mode
virtual
supervisor mode supervisor mode
33
Pro and Con of Virtual Machines
Each virtual machine is isolated from all other
i t l hi l f
virtual machines: c omplete protection of system resources
Effort required to provide an exact duplicate of
th d l i hi
the underlying machine
Perfect vehicle for
Operating-systems research and development
Cross platform development; Example…
Example: Application development for different Operating Systems p g y
35
Operating-System Implementation,
Generation, and Boot
System Design and Implementation y g p
Designing an operating system
U l t li bl f f t
User goals: easy to use, reliable, safe, fast
System goals: easy to design, implement, and operate
Highly creative task
Highly creative task
Uses software engineering principles
General design principle: Separation of policy from mechanism
M h i h d hi
Mechanism: how to do something
Policy: what will be done
Example: Timer construct and timeout length
Example: Timer construct and timeout length
Maximum flexibility if policy decisions are to be
Maximum flexibility if policy decisions are to be changed later
37
System Design and Implementation y g p
Traditionally written in assembly language
Code written in a high-level language like C or C++
Can be written faster
Is more compact
Is easier to understand and debug
Easier to port
Easier to port
Particular speed and memory requirements
Major improvements by data structures and algorithms
Replace bottleneck routines by assembly language
Improvements in compiler technology
Improves the compiled code
System Generation (SYSGEN) y ( )
Operating systems are designed to run on any of a class of machines
SYSGEN: OS configured or generated for each specific computer site Determine required information
Determine required information
Read specific information from editable file
Probe the hardware directly
Required information: CPU options, available memory, available devices, OS options
Building the system
At one extreme: Modify a copy of the source and compile from scratch
Conditional compilation
Conditional compilation
Link precompiled modules
At the other extreme: Table-driven
39
System Boot y
Starting a computer by loading the kernel
Small devices (e g cell phone) OS resides on ROM
Small devices (e.g. cell phone) – OS resides on ROM
Duplicated into RAM; RAM is faster than ROM
Otherwise
Bootstrap loader stored in ROM
Bootstrap loader stored in ROM
Kernel stored on disk
Bootst ap loade
Bootstrap loader
Run diagnostics
Read the boot block
Execute Bootstrap program
Bootstrap program
Bootstrap program
Load and execute remaining part of the bootstrap program
Locate kernel in file system
Summary and References
Summaryy
Operating system services are needed for the user and for the OS itself
and for the OS itself
Operating system services are found at different levels (system calls, command interpreter, System Call APIs
( y , p , y
(POSIX is one well known API), ...)
System services typically provide complex functions by frequently issuing different system calls
frequently issuing different system calls
Designing complex operating systems
Operating systems are a complex piece of software; p g y p p ; methods from software engineering useful
Modularity is important: microkernel and modules Separating mechanism from policy is a good idea
Separating mechanism from policy is a good idea
Virtualization: virtual machines (already known for a long time) have become popular
References
Silberschatz, Galvin, Gagne, „Operating , , g , „ p g
System Concepts“, Seventh Edition, Wiley, 2005
2005
Chapter 2 „Operating-System Structures“
43
