Operating Systems 2010/2011

Transcription

1 Operating Systems 2010/2011 Introduction Johan Lukkien 1

2 Agenda OS: place in the system Some common notions Motivation & OS tasks Extra-functional requirements Course overview Read chapters

3 A computer system consists of hardware system programs application programs separation between kernel and user mode OS: place in the system 3

4 Example interaction: read data from file Interaction is named: system call Execute C statement: status = read(fd, buffer, nbytes) read nbytes bytes from fd, storing it in buffer is part of a program running on top of the OS (e.g. banking program) memory: kernel space/user space kernel space only accessible with processor in kernel mode parameters: either via registers or via memory 1-3: pushing parameters 4: call library function 5: put code for read in reg. 6: trap (Linux@x86: int 0x80): switch mode and call trap handler 7: handler calls read function handler 8: handler performs read actions (a.o. store data at address). Here suspension of the calling process may occur if data needs to come from an io device. 9-11: control back to caller suspension possible picture from slide by A.S. Tanenbaum 4

5 status = read(fd, buffer, nbytes) The filepointer, fd, refers to a data structure (probably within the kernel space) that stores information where the file is to be found current access state (particularly, the read position)... The requested data is found in system buffers that store disk blocks already available or needing disk access Copying data from the disk to these buffers is by hardware read requests that specify disk block and destination buffer issue the disk operation and wait for completion interrupt The file system may do look-aheads concurrently with user activities When this data is not available in system buffers at the time of reading suspension of the calling process results. Similar suspension occurs when the process has consumed its alotted time. 5

6 OS required basics from processor Two modes, supported by the processor supervisor (kernel, privileged) and user mode some processors support a series of modes for increasing privileges Intel: 4 rings Transfer of control to kernel (i.e., transfer to code executed in kernel mode) interrupt: external source e.g. clock tick, i/o completion trap: internal (software) source system call (explicit SuperVisor Call or SVC), in line with control flow of program generated software error (e.g. floating point error) Using these modes, guarantees can be given regarding protection 6

7 Example interaction: a user using the OS Access to a machine is through system programs (e.g. login program, a command interpreter, a GUI) logon sequence, resulting in OS API calls and internal checks by the OS after login, a default environment, a view on the road is given graphical desktop, shell A user can usually adapt her environment; however, the system part of the environment is under OS control Example (unix): user authenticates: username, password combination accepted and interpreted by a special system application: login the system information of the user is maintained inside the OS throughout the session and is determined through this authentication procedure a shell is started that interprets inputs (typed command lines, or mouse clicks) issues commands accordingly amounting to the execution (starting & running) of some application program this login program and shell are also just applications 7

8 Agenda OS: place in the system Some common notions Motivation & OS tasks Extra-functional requirements Course overview 8

9 Policy and mechanism Policy: what you want a system to do, to behave Mechanism: something that a system or component is able to do, how it does it Policies need appropriate mechanisms for their realization The policy provides the abstraction Examples: policy: increase home-ownership mechanism: tax deduction policy: execute task with earliest deadline mechanism: priority based scheduling & pre-emption 9

10 The notion of transparency Transparency: hide details with respect to some given issue Examples: processor architecture (ISA) mechanism: compiler physical memory size mechanism: virtual memory physical location mechanism: indirection distribution mechanism: indirection 10

11 Virtualization Virtualization: presenting an abstracted, virtual model Implies transparency... with respect to some implementation details... but adds to that that some new logical model is presented virtual machine, virtual memory, virtual disk Current systems virtualize the entire hardware 11

12 Layering and virtualization A layer with a well-defined API yields in fact a virtual machine for a programmer, the virtual machine is what he sees porting programs amounts to porting such virtual machines Virtualization can support several OS s on top of one OS (right) implemented in a run-time system (e.g. VMware) This virtualization can go down to immediately above the hardware (left) virtual machine monitor, hypervisor 12

13 Java virtual machine Other examples compilation comp..net Framework 13

14 Agenda OS: place in the system Some common notions Motivation & OS tasks Extra-functional requirements Course overview 14

15 Main system components & diversity CPU and main memory are required for basic operation There are many alternatives diverse CPUs Instruction Set Architecture diverse organization (a) multi processor with shared memory (e.g. current multi-core systems) (b) multi computer with private memort and shared file system (e.g. cluster) (c) independent computers on a network (e.g. cluster, but also, internetconnected machines) even application dependent 15

16 OS Motivation: diversity Machines & machine architectures are diverse Instruction Set Architecture, memory model provided by the ISA collection and type of connected devices differs per machine OS task: realize the following transparencies hide inner workings and details of platform processor, # processors, particular devices note: also compiler plays a role in this abstract from the complicated memory hierarchy and physical limitations present linear memory model, larger than physical called: memory virtualization 16

17 OS Motivation: shared functionality Large collection of services is needed by virtually all programs e.g. file model & file access, error handling, memory allocation OS task: provide functionality common to most programs introduce well-defined abstractions or concepts files and filesystems instead of disk blocks exceptions and traps rather than something goes wrong linear memory rather than memory blocks, pages and disk space provide libraries of functions (APIs) for manipulating the concepts 17

18 OS Motivation: concurrency The machine must be shared: multiple activities ( tasks, processes ) & multiple users unavoidable: devices and processor operate concurrently many common OS tasks are reactive; termination is rare efficiency: hide waiting times OS tasks: realize concurrency transparency (virtualization) each task virtually has the machine of its own that is, the virtual machine provided by the OS API manage and protect (enforce) resource usage processor, memory, i/o equipment, keyboard, mouse, screen, disks, network and other communication facilities,... between tasks and between users 18

19 OS Motivation: portability Protect investments in application software support source code portability OS task (or: design criterion) (see: shared functionality) give a unified machine view to applications i.e., a portable view, a good abstraction of commonly used architectures... standardize on an API effectively, that defines a virtual machine... the POSIX initiative 19

20 The OS common API chapters Process management create, destroy, communication, synchronization,... File management open, close, read, write, Memory management allocation, free, virtual memory Device management access control, open, attach, send/receive Communication setup communications, exchange messages, Miscellaneous timers, inspect system resources 20

21 Agenda OS: place in the system Some commons notions Motivation & OS tasks Extra-functional requirements Course overview 21

22 22

23 OS extra-functional requirements Efficiency the sacrificed efficiency (of having an OS rather than direct access) should be reasonable tweakable : control by programmer applications must be able to obtain close-to-optimal machine use example: provide raw disk access as well as file systems rule of thumb: if a (new) function can be implemented with the available ones, don t provide it unless this indirect implementation needs to sacrifice an unreasonable amount of performance example: provide buffered i/o but leave structured files outside kernel because unbuffered i/o without kernel support costs too much performance 23

24 Extensible OS extra-functional requirements support for adding application-specific (domain-specific) functionality Scalable wide range of environments, functionalities, machines Dependable robust, correct, safe & secure level dependent on application domain 24

25 Domain-specific requirements Real-time OS predictability known performance versus high performance (all resources) maximum latencies (response times) of API calls support for dealing with real-time control (pre-emptive) scheduling policies explicit control over resources real-time facilities: clocks and timers stringent dependability Embedded OS small footprint (e.g., leave all superfluous parts out) low system requirements (e.g. processor speed, energy) stringent dependability Multi-processor OS 25

26 Abstraction Summarizing - OS views provide useful generic concepts... to handle complexity Virtualization provide the same abstract model for a wide range of underlying systems... to aid in sharing each process/user sees single machine, linear memory Resource management sharing, protection optimize performance accounting and access control 26

27 OS required basics Two modes, supported by the processor supervisor (kernel) and user mode privileged instruction in supervisor mode Transfer of control to kernel (i.e., transfer to code executed in kernel mode) interrupt: external source e.g. clock tick, i/o completion trap: internal (software) source system call (explicit SuperVisor Call or SVC), in line with control flow of program generated software error (e.g. floating point error) Memory protection hardware Timers 27

28 Agenda OS: place in the system Some commons notions Motivation & OS tasks Extra-functional requirements Course overview Read chapters

29 Course Program Introduction Concurrency Sequential processes Interleaving and interference Communication and Synchronization Processes, Threads and Scheduling Memory management Input/output general issues file systems (Security & protection) Note: both specification (usage) and implementation aspects 29