Operating System Overview Memory Chipset I/O bus Otto J. Anshus - PowerPoint PPT Presentation

A Typical Computer from a Hardware Point of View . . . CPU CPU Operating System Overview Memory Chipset I/O bus Otto J. Anshus (including slides from Kai Li, Princeton University) University of Tromsø Network Keyboard Kai Li/OJA A Typical Computer System Typical Unix OS Structure Memory C CPU Application •...have to Programs and data . . Assembler •Performance . Operating System Software Standard library CPU •Low-level system initialization and bootstrap •Fault, trap, interrupt and exception handling Portable OS Layer •Memory management: hardware address translation OS Network Machine-dependent layer •Low-level kernel/user-mode process Apps context switching Data •I/O device driver and device Keyboard initialization code System Call Interface Kai /iOJA Kai Li/OJA

Memory Linux Kernel version 2.0 Address 0-255 byte word byte • 500,000 lines of C code and 8000 lines of assembler Instructions • “Micro kernel” (process & memory management): 5% Data • Device drivers: 90% • Network, file systems, initialization, etc.: 5% Intel architecture is “little endian” Hexadecimal Unix “Onion” • 16 decimal is base Applications User Level - Kernel Level • 0, 1, 2,…,9, A, B, C, D, E, F Boundary • C4AFh=50351d Operating system • C*16 3 + 4*16 2 +A*16 1+ F*16 0 Device • 12*16 3 + 4*16 2 +10*16 1+ 15*16 0 = 50351d • 2 8 -1=11111111b =255d =FFh Hardware 2 16 -1=1111111111111111b =65535d =FFFFh • • 2 32 -1=1111111111111111…1b =4294967295d =FFFFFFFFh drivers

Check it out: User vs. Kernel Level on Windows User level vs. Kernel level NT • Kernel (a.k.a. supervisory or privileged) level • Start the PerfMon (start->administrative tools) • All instructions are available • add %user time and %privileged time • Total control possible so OS must say “Mine, all mine” (Daffy Duck) • Move the mouse around • User level • %pt spikes • Some instructions are not available any more • Grab the perf mon window and move it around • Programs can be modified and substituted by user • %pt peaks In theory, but not always in practice The Service Model OS Service Examples • A.k.a. the client/server model • Examples that are not provided at user level • Model of interaction Request – File open, close, read and write • Used in both centralized and – Control the CPU, or a single user takes over by doing distributed systems while ( 1 ) ; • Client can be Server and vice versa – Protection: Reply • Keep user programs from crashing OS • Keep user programs from crashing each other • Examples that can be provided at user level Procedure Calls, System Calls, Traps, Interrupts, Shared Variables, or – Read time of the day Message Passing – Protected user level stuff Kai Li/OJA

Discussion topic: Window System part of the OS OS Responsibilities (1) (1)? • Yes: • Job control – Windows NT • Start, stop, kill • Window Manager runs in Kernel Mode • User interface • Integrated with Graphic Device Drivers • Job Control Language (JCL) Interpretation • Can not easily use several file systems at the same time or use another FS • Window system than NTFS Part of the OS? • Error handling • Performance benefit • No: • Protection – Unix • I/O handling • X runs in User mode • Interrupt handling • Flexibility and “openness” • Hardware • More overhead • Software Discussion topic: Window System part of the OS OS Responsibilities (2)? • Solution space: • Resource Control • All in Kernel – Sharing • All at user level • Scheduling • Must protect the display device or chaos possible – CPU • Split between Kernel and User level – Memory (Registers, cache, memory (main, remote, disk) • Display drivers in Kernel – I/O (network, interconnect, busses) • Multi access • Rest at User level – Accounting

OS Characteristics OS Characteristics Single process- single user • Concurrency • Efficiency Single process - Multi user? • Switching between tasks • Overhead (low) Multi process - Single user • Mutual exclusion • OS resource use (low) Multiprogramming Multi process - Multi user • Condition synchronization • CPU idle time (low) • Throughput (high) • Sharing High & Long • Response time (short) Low and Short • Allocation of resources • Fairness (yes, but what if not?) • Concurrent access to data and other resources Starvation • Reliability • Concurrent program execution • Protection of all resources including data and programs • Error isolation • Graceful degradation History: CPU waiting for I/O Processor Management • Goals CPU I/O CPU • Assume – Overlap between I/O and • 1200 card program :-) computation CPU CPU • The assembler speed: 300 cards/sec – Time sharing • Card reader: 20 cards/sec I/O – Multiple CPU allocations • Observations • Issues • 60 seconds to read program to memory CPU • CPU runs the assembler for 4 seconds – Do not waste CPU resources I/O • Implication – Synchronization and mutual CPU • CPU is idle for 56 seconds = 93.3% of the time CPU exclusion • CPU utilization is 6.7% – Fairness and deadlock free CPU • CPU and I/O device alternates, no overlap or interleaving Kai Li

Memory Management Registers and memory • Goals – Support programs to run Register – Allocation and management L2 10x – Transfers from and to secondary storage Memory 200x • Issues – Efficiency & convenience Disk 10Mx – Fairness Tape 100Mx – Protection Kai Li System-level Registers I/O Device Management • Goals User 1 . . . User n – Interactions between devices and applications – Ability to plug in new devices Library support • Issues Driver Driver – Efficiency – Fairness I/O I/O . . . – Protection and sharing device device Kai Li

OS Characteristics File System • Storing of data and programs • A typical file system Part of the OS? User 1 User n . . . • Simple and fast access – Open a file with User vs. Kernel Level? • Protection against programs authentication – failures – Read/write data in files – intentional File system services – Close a file • Protection against system • Can the services be moved to – failures – intentional user level? • Non-deterministic File File . . . • Time independence Kai Li Discussion topic: User level FS? OS Characteristics (4) • Yes: Minix • Management • FS as a “server” at user level • Simple • almost a user process... • Modular • ...but booted together with OS • Well defined interfaces • …and never terminates • Good documentation • …and gets higher CPU priority • Small size • …and a new server means recompiling the kernel • Simpler • disk drivers at Kernel level • Less bugs • NO: Unix and Windows NT • Cheaper • File system at Kernel level • Faster

Discussion topic: Network boot Ways to Develop An Operating System • Need “netboot” code in EPROM • A hardware simulator • Netboot must • A virtual machine • Understand the network protocols (Ethernet, TCP/IP, something) • A good kernel debugger • download boot code from a server – When OS crashes, always goes to the debugger • execute boot code to download OS – Debugging over the network • Issues • Client must – have name of server and of self • Server must have a database of clients • Security, Protection, Restrictions Kai Li