Operating Systems 1 (3/12) - Architectures

Operating System Architectures

Beuth HochschuleSummer Term 2014

Operating Systems I PT / FF 14

Operating Systems

2

Operating Systems PurposeOperating Systems Purpose

System software that manages resourcesSystem software that manages resourcesOS hides complexity of underlying hardwareOS hides complexity of underlying hardwareLayered architectureLayered 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) T

anen

baum

200

1

Computer Hardware

Operating System

Utilities

Application Programs

End UserProgramm

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


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

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 memoryaddress space

0x00000000 0xFFFFFFFF 0x00000000 0xFFFFFFFF 0x00000000 0xFFFFFFFF





• 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 timeif 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


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


(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

http://en.wikipedia.org/wiki/List_of_Linux_supported_architectures


(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


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


(C) Layered Architecture

10

(C) Stallings


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


Layered Architecture

• System call

• Mode change of the CPU - „trap“

• Parameter transmission possible via trap parameter, register or stackcount=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 systemsUnstructuredUnstructuredSupervisor call Supervisor call changeschanges

App App

System services

User ModeKernel Mode

34

fromfrom user mode inuser mode intotokernel modekernel mode

Hardware

OS procedures


Example: Linux

13

(C) Stallings



• 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--level level interfacesinterfaces

ApplicationProgram

ApplicationProgram

ApplicationProgram

User Mode

35

System Services

File System

Memory and I/O Device Management

Processor Scheduling

Hardware

User Mode

Kernel Mode


Example: VMS and Windows

15

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/VMSoperating system OS/2 Windows

POSIX

Environment Subsystems

UserApplication

Subsystem DLLUserModeKernelMode

System& ServiceProcesses

Windows

46

System-wide data structures

Memory Management I/O Subsystem Process and

time management

System servicesKernel

Record Management Service (RMS)Executive

Command Language Interpreter (CLI)Supervisor

Platform-Adaptation Layer (PAL) - Alpha

Support LibrariesUtilities

User

Windows high-level architecture

WindowsUser/GDIDeviceDriver

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/VMSoperating system OS/2 Windows

POSIX

Environment Subsystems

UserApplication

Subsystem DLLUserModeKernelMode

System& ServiceProcesses

Windows

46

System-wide data structures

Memory Management I/O Subsystem Process and

time management

System servicesKernel

Record Management Service (RMS)Executive

Command Language Interpreter (CLI)Supervisor

Platform-Adaptation Layer (PAL) - Alpha

Support LibrariesUtilities

User

Windows high-level architecture

WindowsUser/GDIDeviceDriver

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)



• 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:SchedulingSchedulingMemory Memory

MemoryServer

ClientApp

Network Server

ProcessServer

FileServer

DisplayServer

38

Memory Memory ManagementManagementInterprocess Interprocess communication communication (IPC)(IPC)

UserUser--mode serversmode servers

Microkernel

Hardware

request

reply

User ModeKernel Mode



17

(C) Stallings


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 CallsUser

Kernel

UNIX OS API

Unix Operating

System Flavor (BSD / SYSV)

System Calls


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


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

http://de.wikipedia.org/wiki/American_National_Standards_Institute

Date post:	12-Jul-2015
Category:	Education
Upload:	peter-troeger
View:	209 times
Download:	1 times

Operating Systems 1 (3/12) - Architectures

Education