Operating System Structures Outlook
Oppgerating-System Services
System Call Perspective on Services
OtiOperating-StSystem SttStructure
Operat ing -System Im pl em en tati on , Generation, and Boot
2 Operating-System Services Services can be provided at different levels
Command interpreter Command interpreter Shell: read and interpret control statements Process creation and management, I/O handling , secondary-storage management, System programs main memory management, file- system access, protection, netkitworking, … Or a mouse-based window and menu system System call API System Programs See Windows Systemsteuerung for examples Ressources System Call API E.g. File Open/Read/Write/Close- Interface Ressources e.g. buttons, … 4 Oppgyerating System Service Classes
Services intended for the user
Uitf(CLIbthGUI)User interface (CLI, batch, GUI)
Program execution
I//pO operations
File-system manipulation
Process communications (shared memory, message passing)
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
Accounting for billing or statistics
Protection and security
Essential Components? 5 Process management
Process = Program in execution CildCompiler, word-processittking program, system task A process requires resources CPU time, memory , files , I/O devices Processes may run concurrently
Operating system is responsible for 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
6 Memoryyg Management
Large array of words or bytes
Each word or byte has its own address
Accessible by I/O and CPU
Many programs in memory requires memory 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
Uniform logical view on information storage
File: Logical storage unit
Organized in directories
Independent of the storage media
Control access permissions
Operating system is responsible for
Creating and deleting files and directories
Primitives for manipulating files and directories
Loading or mapping files into RAM
Backing up files on stable storage media
8 Further Syyp()stem Components (1)
I/O-Syygstem Management
Managing buffering, caching, and spooling
General device driver interfaces
Device drivers hiding device peculiarities
Secondary storage management
Free-space management
Storage allocation
Disk scheduling
9 Further Syyp()stem Components (2)
Networking PidProvide access t o net wor kdked resources Hide networking hardware by a file access like interface
Protection system Control access of programs to files, memory, CPU, …
10 Syygstem Programs and Utilities
File management Status information File modification Programming-language support Program loading and executing Communications
Utilities often come with OS distribution but do not participate in the OS operation
Browser, word processor, text formatter, spreadsheet, database,,p plotting, statistical analy sis, ,g games
11 Imppgortant Program: Command Interp reter
Possible implementations
Command interpreter contains the command code
Command interpreter loads command programs
Pro and con of loading command programs
Extendibility
Command and interpreter exceeding memory size
Performance
Inconsistent parameter interpretation
12 System Call Perspective on Services System Calls
Interface between process and operating system AilblAvailable for examp le as tag">C or C ++ lib rary routi nes (For certain low level tasks assembly-language instructions might also be useful (e .g . asm {} pragma in C))
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
Fact: System calls are frequently (thousands per second)
14 System Call Interface
0xfe00 mov #13, d0; 0xfe04 trap 42;
15 Passinggy Parameters to System Calls
Possibilities: regg,isters, memory block (table), stack
Example: passing parameters as a table 16 System Calls: Process Control
end, abort (core dump debugging, error level) load, execute (what happens with the calling program?) create/terminate process get/set process attributes (priority, maximum execution time) wait time, wait event, signal event allocate/free memory dumppgpp, trace, single step, profile (used for debugging) 17 Syygstem Calls: File and Device Management
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
OS can provide common system calls for files and IO open, close read, write, reposition gg/et/set attributes
Consider /dev in Unix systems for example
18 Further System Calls
Information maintenance get/set system data Time, date, number of users, version, memory space, disk space, …
Communication (message-passing modl)del) open/close connection Requires addressing: Process-ID (, Host-ID) Realized as separate functionality or like file access accept/wait for connection get hostid or processid (for a given process name, host name) send/receive messages
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
Examples: Win32, Example ANSI C API, POSIX API
Invoke the system call on behalf of application
Benefits
Portability
Simplification of compltlllex system calls
20 Portable Oppgyerating System Interface ( POSIX)
Gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface (API), das die Schnittstelle zwischen Applikation und dem Betriebssystem darstellt. 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. 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, 2004 Edition veröffentlicht. Die gegenwärtig aktuelle Version ist die Überarbeitung von 2008. 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 Oppgyerating System Interface ( POSIX)
Die Spezifikation der Benutzer- und Software- Schnittstelle des Betriebssystems ist in vier Teile unterteilt, die zusammen den Standard IEEE Std 1003.1- 2008 bilden: BiBasis-DfiiiDefinitionen Eine Liste der im Standard benutzten Konventionen, Definitionen,,p und Konzepte. System-Schnittstelle Die C-Systemaufrufe und dazugehörige Header-Dateien. Komman doze ilen int erpret er und Hilf sprogramme Eine Liste der Hilfsprogramme und der Kommandozeileninterpreter. Erklärungen Erläuterungen, warum der Standard so ist, wie er ist.
Quelle: Kopie aus http://de.wikipedia.org/wiki/Portable_Operating_System_Interface 22 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.
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, RTEMS (POSIX 1003.1-2003 Profile 52), Solaris und 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) BeOS und 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 Kompatibilität serwe iterung o der e iner Zw isc henschi cht üb er d em KlKernel) Die NT-Kernel (XP, Win7, Win8 liegen z.B. in der NT-Linie) von Microsoft Windows bei Nutzung der Microsoft Windows Services for UNIX Unterstützung von Untermengen wie die Posix Threads wird 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 ixemul .lib rary
Quelle: Kopie aus http://de.wikipedia.org/wiki/Portable_Operating_System_Interface 23 Operating-System Structure Syypstem Structure: Simple
Example: MS-DOS
25 System Structure: Monolithic
Examppgle: original UNIX sy stem structuring
26 Syyy()stem Structure: Layered (1)
27 Syyy()stem Structure: Layered (2)
Advantage Layers hide details to higher -level layers Incremental debugging and verification
Major diffic ult y: defining the right la ye r f unctions and o rde rings 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.gg/p/y. user calls I/O operation: I/O layer memoryyg management lay er CPU-scheduling layer hardware
28 System Structure: Microkernel
Kernel consists of minimal set of services Process management Memory management Communication facility NtiltlidNonessential components realized as user-lllevel programs Components always interact via microkernel
Benefits Extendibility Portability Security and reliability Drawbacks Performance decreases due to increased system overhead Experience with Win95, early Win NT, and Win XP Example systems: Mach, Tru64 UNIX, QNX
29 System Structure: Modules
OOP techniques to create modular kernel
Modules are well defined by interfaces
Modules interact without message passing
No ldlayered 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)
30 Module vs. Microkernel
Modules Component A Component B all modules reside in kernel space no message passing via microkernel better than layering: any module can call any other
Microk ernel Microkernel components reside in user space communication via message passing; expensive
Kernel Space
31 System Structure: Virtual Machines
Non-virtual Machine Virtual Machine
Examples: VMware, Java VM, .NET CLR, UML 32 Implementation
Example: How to realize dual mode in user space? trap into kernel first requires some kernel support
Example: Communication Via file system Via Software defined network of VMs virtual user mode
virtual user mode supervisor mode
supervidisor mode
33 Pro and Con of Virtual Machines
Each virtual machine is isolated from all other vitirtua l machines: complete protection of system resources
Effort required to provide an exact duplicate of the un derl yi ng machi ne
Perfect vehicle for
Operating-systems research and development
Cross platform development; Example…
34 Example: Application development for different Oppgyerating Systems
35 Operating-System Implementation, Generation, and Boot Syygpstem Design and Implementation
Designing an operating system UlUser goals: easy t o use, reli liblfftable, safe, fast System goals: easy to design, implement, and operate Highly creative task Uses software engineering principles
General design principle: Separation of policy from mechanism MhiMechanism: h ow to d o somethi ng Policy: what will be done Example: Timer construct and timeout length
Maximum flexibility if policy decisions are to be changed later 37 Syygpstem Design and Implementation
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
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 Can do complex analysis
38 Syy()stem Generation (SYSGEN)
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 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 Link precompiled modules At the other extreme: Table-driven
39 System Boot
Starting a computer by loading the kernel Small devices (e. g. cell phone) – OS resides on ROM Duplicated into RAM; RAM is faster than ROM Otherwise Bootstrap loader stored in ROM Kernel stored on disk
Bootstr ap loader Run diagnostics Read the boot block Execute Bootstrap program
Bootstrap program Load and execute remaining part of the bootstrap program Locate kernel in file system Load it into memory Start its execution 40 Summary and References Summary
Operating system services are needed for the user and for the OS itself Operating system services are found at different levels ((ysystem calls, command interp reter, Sy stem Call APIs (POSIX is one well known API), ...) System services typically provide complex functions by frequently issuing different system calls Designing complex operating systems Oppgyerating systems are a comp pplex piece of software; methods from software engineering useful Modularity is important: microkernel and modules Separating mechanism from policy is a good idea Virtualization: virtual machines (already known for a long time) have become popular
42 References
Silberschatz, Galvin, Gagne,,„ „O perating System Concepts“, Seventh Edition, Wiley, 2005
Chapter 2 „Operating-System Structures“
43