Chapter 2 Operating System Structures

Chapter 2

Operating System Structures

User Services

User Interface

Command Line Interface – commands entered via keyboard

Batch Interface – commands are placed in text file which is executed Graphical User Interface – icons, menus, point, click, keyboard Program Execution I/O Operations File-System Manipulation Communications Shared Memory Message Passing Error detection Hardware Software

Efficient Operation

Effective User Identification (EUID) Security

Authentication of Users Securing I/O Device Access

Monitoring Invalid Access Attempts Virus Scanning

Command Interpreter

Some operating systems provide a kernel resident command interpreter Windows XP

Unix

The purpose of a command interpreter is to get and execute the next user specified command command interpreter contains the code necessary to execute the command

uses the command to identify a file to be loaded into memory and executed contains shell scripting languages for easy manipulation of command line strings Shells – command interpreters provided by vendors, users or third parties

Bourne Shell C Shell

Bourne-Again Shell Korn Shell

Bash Shell

Graphical User Interfaces

Desktop Metaphor (Xerox PARC Research Facility circa 1971-1972) Icons

Menus Files

Folders (directories) Apple – MacIntosh circa 1980 Unix

Common Desktop Environment (CDE) X-Windows

Open-Source GUI

K Desktop Environment (KDE) GUI – GNOME

System Calls

Interface between user programs and O/S service routines API Application Programming Interface

o specifies a set of functions available to facilitate system calls o program portability

Win 32 API -- Windows

POSIX -- UNIX, Linux, Mac OS/X Java API -- JVM

Run-Time Support System

o provides a system-call interface

o intercepts function calls from the API & invokes the system call in the kernel Silberschatz page 57 Win32 API example

Silberschatz page 58 figure 2.6 Passing Parameters

pass parameters in registers

store parameters in a memory block; pass the block address o Linux, Solaris

o Silberschatz page 59 figure 2.7 push parameters onto the stack Process Control

abort( )

error trap( )  memory dump  debugger  runtime errors exit( )

wait( )  wait for spawned process to complete execution and return result fork( )  spawn an process for independent execution

exec( )  loads new process into memory and initiates execution

lock( )  reserve resources, e.g., file1, for exclusive use by process issuing the call release( )  releasing the locked resources

printf( )  Standard C Library  invokes write( ) system call in O/S

O/S write( ) system call returns value to Standard C Library which returns it to printf( ) Silberschatz page 62 figure 2.9

FreeBSD memory map

Silberschatz page 63 figure 2.11 Actions following Process Termination Command Interpreter  reads next command GUI  popup window asks for guidance Batch 

terminates job; continues with next job

reads control card for special error code instructions Error Codes

0  normal termination

File Management create( ) open close( ) delete( ) read( ) write( ) mkdir( ) rmdir( ) get_attribute( ) set_attribute( ) Device Management acquire( ) release( ) Information Management date( ) returns date & time who( )

version( )

trace( )  provides for run-time trace 

requires hardware support to execute a trap after every instruction profile( )  returns execution statistics

Communication message-passing

OR

shared-memory

Protection

see Silberschatz Chapters 14 & 15

Unix

File-Device Management Policy -- devices are treated as if they were files

Process Name A Host Name ●●● IP Address ●●● Process Name B Host Name ●●● IP Address ●●● Shared Memory Process Name A Host Name ●●● IP Address ●●● Process Name B Host Name ●●● IP Address ●●● Mailbox

System Programs – System Utilities

System Status Information performance information

configuration information, e.g., registry File Modification

text editors grep, sed, awk tr, etc.

Programming Language Support compilers

assemblers

source code debuggers interpreters Execution Utilities absolute loaders relocatable loaders link editors overlay loaders run-time debuggers Communication

O/S Design & Implementation

Separation between

Policy – what will be done

Mechanism – how to do something

Solaris scheduler – table driven  time-share, batch processing, real-time, fair share Windows & Mac OS/X  scheduler policy & mechanism is built into the kernel Implementation

C  Linux assembly language  register management & device drivers

C/C++  Windows assembly language  register management & device drivers

C or C/C++ Unix (all versions) assembly language  register management & device drivers Areas of Critical Performance

o memory manager o CPU scheduler

O/S Structure

IBM OS/360-390  Monolithic Structure  Frederick Brooks  Mythical Man-Month MS DOS  limited hardware support  not an O/S, i.e., NAOS  page 71 figure 2.12 Original Unix  limited hardware support  monolithic tendencies page 71 figure 2.13

Layered Structure

Microkernels

Carnegie Mellon University  Mach O/S

o remove nonessential components from the kernel o implement them as system programs

microkernels provide

o minimal process management o minimal memory management o full communications

 between client programs and services running in user space  uses message-passing

new O/S services run in user space

Digital Unix, i.e., Tru64 Unix Unix interface, Mach kernel Mac OS/X kernel – Darwin

QNX – real-time system Modules

Object-Oriented Design & Development  Dynamically Loadable Modules Solaris, Linux, MacOS/X

Solaris design Silberschatz page 75 figure 2.15  more flexible than layered approach Mac OS/X hybrid design Silberschatz page 75 figure 2.16

o Mach + BSD comprise kernel o Mach provides

 Memory Mngt (MM)

 Remote Procedure Calls (RPC)Interprocess Communications Facilities (IPC)  Message-Passing

 Thread Scheduling o BSD provides

 Command-Line Interface  Networking Support  File System Support

 POSIX API including Pthreads Hardware Layer

Layer N Layer 0 Layer 1 ●●●

Difficult to Specify the Levels for Selected Components due to Conflicting Requirements

Windows NT (version 1)  Reduced Efficiency, Increased Size Windows XP  Reduced Layering, Increased Functionality

Virtual Machines

host O/S provides an interface that is identical to the underlying bare hardware guest O/S is provided with a virtual set of hardware

IBM VM370

o created multiple virtual machines o supported IBM CMS – single user O/S Benefits

o Sharing Host Resources with Strict Protection from other Virtual Installations o Sharing Resources between Virtual Installations, e.g., disk space

o Operating Systems Research & Development  Installing prototype O/S for testing

 Reinstalling Production O/S for further development

o multiple O/S available on the developers workstation concurrently o production data center consolidation – resource optimization

Simulation – Emulation

Host has a systems architecture different than that of the Guest

Emulation program translates each of the Guests instructions into the native instruction set of the Hosts system

XP emulator for MS DOS

Performance Issues – a program running on an emulator will run an order of magnitude slower than the old program

Not all features may be capture in the emulation program

Parallels Emulator running on Mac OS/X supporting other Operating Systems

Para-Virtualization

Solaris 10 zones (containers)

Operating System & Devices are virtualized

provides each process with a zone; as if they were the only process on the system virtual user mode

virtual kernel mode

those actions that cause a transfer from user mode to kernel mode on the physical machine 

must cause a transfer from virtual user mode to virtual kernel mode on the virtual machine Implementation

virtual machine in virtual user mode issues a system call 

transfer of control to the real machine virtual-machine monitor 

virtual-machine monitor can

o change register contents & program counter to reflect the virtual system call o change the virtual mode from user to kernel

o restart the virtual machine

VMware Workstation

creates independent virtual Intel X86 machines runs on host O/S, e.g., Linux, Windows

Silberschatz page 81 figure 2.19

system down (development) time

Java Virtual Machine (JVM) Sun Microsystems 1995

Language Specification API Library

JVM specification (abstract computer)

architecture-neutral bytecode file, i.e., (.class file) JVM Components

Class Loader – loads Java program .class files + Java API .class files Java Interpreter of bytecodes

Verifier – checks that .class files are valid bytecode, i.e., o will not underflow nor overflow the stack

o does not perform pointer arithmetic

Garbage Collector – reclaims unused memory as soon as possible JVM Implementation

Software

o interprets bytecode instructions each time they are executed

o JIT (just-in-time) compiler – the first time the bytecode is executed, it is converted to native machine code – the native code is cached for repeat usage

Hardware – special java chip that executes bytecode as native machine code .NET Framework

Common Language Runtime (CLR) – implementation of the .NET Virtual Machine C#

VB.NET

CLR

loads the assemblies into the Application Domain

as the executing program requests instructions, the CLR converts he MS-IL instructions into native code for execution and where they are stored for repeat usage as demanded Silberschatz page 83 figure 2.21

Debugging

Failure Analysis -- Locating Bugs, i.e., Errors Log Files – error information

Core Dump – image of memory at a particular point in time

Debugger – explore the process, i.e., code, registers, memory and other run-time information Kernel Failure – crash

OS detects a kernel failure, it writes the contents of memory to a section of disk w/o a file-system When system reboots, a system process copies the crash dump data to the crash dump file in the file-system

CLR compiles the source code into an intermediate architecture-independent language called Microsoft Intermediate Language (MS-IL); these files, i.e., assemblies, also include metadata and have file extensions of either .DLL or .EXE

Performance Tuning, i.e., Locating Bottlenecks

Hardware implementation – trace listings produced by the hardware Interactive investigative tools – query state of the system

Profiling

periodically samples the IP to determine what code is being executed yields statistical trends

Solaris DTrace Dynamic Tracing Facility Components

Compiler – generates a byte code (ECB) that is run in the kernel to enable o probes

o consumers in user mode

o communications between users and kernel probes Framework

Provider – supplies probes written w/in the Framework Consumer – requests provider create one or more probes Actions

probe created

o kernel provides a HashTable Data Structure to keep track of the probes probe enabled

o a bit of code in the area to be probed is rewritten to call the probe o code continues its original operation

o kernel executes the ECB upon demand probe consumer terminates

o ECB are removed

o if there are no ECB’s consuming a probe, the probe is removed o rewriting the code to remove the probe call

Information Generated kernel system state processes

System Generation

Source Code Modification + Compilation Table Creation

o Modules are selected from a precompiled Library o unselected modules are removed from the system

o selected Modules are linked to create the operational system Table Driven

o entire Library is always part of the system o selection of modules occurs at run-time

Enabling Control Blocks (ECB) contain a list of actions to be performed when a probe fires contains a predicates , i.e., an if statement, to filter performance (whether or not the probe applies to the ECB)

System Boot

bootstrap (loader) program firmware

ROM, EPROM, etc events

reset event  PC loaded with address of bootstrap loader bootstrap loader fragment -- firmware resident

locates boot block -- disk resident

boot block contains remainder of the bootstrap loader loads bootstrap program

o run diagnostics o initialize system o locates kernel o loads kernel