Chapter 2 Operating-System Structures - Google Sites

1 downloads 227 Views 2MB Size Report
Operating System Structure. • Virtual Machines. • Operating System Debugging and Generation. • System Boot. CSD 20
Chapter 2 Operating-System Structures

CSD 204, Spring 2018

Shashi Prabh

1

Outline • Operating System Services • User - OS Interfaces • System Calls, Types of System Calls • System Programs • Operating System Design and Implementation • Operating System Structure

• Virtual Machines • Operating System Debugging and Generation • System Boot CSD 204, Spring 2018

Shashi Prabh

2

Objectives • To describe the services an operating system provides to users, processes, and other systems • To discuss the various ways of structuring an operating system • To explain how operating systems are installed and customized, and how they boot

CSD 204, Spring 2018

Shashi Prabh

3

Three Viewpoints of OS • User’s view – Focuses on the services that the system provides

• Programmer’s view – Focuses on the interface that it makes available to users and programmers

• OS Designer’s view – Focuses on its components and their interconnections CSD 204, Spring 2018

Shashi Prabh

4

A View of Operating System Services

Provides an environment for execution of programs, and services to programs and users CSD 204, Spring 2018

Shashi Prabh

5

Operating System Services OS services that provide functions helpful to the user and the programmer • User interface (UI): Provided by almost all operating systems – Command-Line (CLI), Graphics User Interface (GUI), Batch

• Program execution – Load a program into memory and run it – End execution • Normally or abnormally (indicating error) CSD 204, Spring 2018

Shashi Prabh

6

Operating System Services • I/O operations – Fulfill I/O requirements of a running program • File or an I/O device

• File-system manipulation – Programs need to read and write files and directories, create and delete them, search them, list file Information, permission management, etc. CSD 204, Spring 2018

Shashi Prabh

7

Operating System Services • Communications – Processes may exchange information, on the same computer or between computers over a network • Communications may be via shared memory or through message passing – packets moved by the OS

CSD 204, Spring 2018

Shashi Prabh

8

Operating System Services • Error detection – OS needs to be constantly aware of possible errors • May occur in the CPU and memory hardware, in I/O devices, in user program, in kernel itself • For each type of error, OS should take the appropriate action to ensure correct and consistent computing • Debugging facilities can enhance the user’s and

programmer’s abilities to efficiently use the system CSD 204, Spring 2018

Shashi Prabh

9

Operating System Services OS services for ensuring the efficient operation of the system itself via resource sharing

• Resource allocation – When multiple users or multiple jobs are running concurrently, resources must be allocated to each of them • Many types of resources - Some (such as CPU cycles, main memory, and file storage) may have special allocation code, others (such as I/O

devices) general request and release code CSD 204, Spring 2018

Shashi Prabh

10

Operating System Services • Accounting – To keep track of which users use how much and what kinds of computer resources

• Protection and security – Access of information stored in a multiuser or networked computer system needs to be controlled – Concurrent processes must not interfere CSD 204, Spring 2018

Shashi Prabh

11

Operating System Services – Protection involves ensuring that all access to system resources is controlled – Security of the system from outsiders requires user authentication, extends to defending external I/O devices from invalid access attempts

• If a system is to be protected and secured, precautions must be taken throughout – A chain is only as strong as its weakest link CSD 204, Spring 2018

Shashi Prabh

12

OS Services: Summary

CSD 204, Spring 2018

Shashi Prabh

13

User OS Interface – CLI • Command Line Interface (CLI) or command interpreter allows direct command entry • Implemented in kernel or by systems program – If the latter, commands may be built-in or names of programs – *nix OSes provide multiple flavors – shells – Primarily fetches a command from user and executes it: cp hello_world.c hello.c CSD 204, Spring 2018

Shashi Prabh

14

Bourne Again Shell

CSD 204, Spring 2018

Shashi Prabh

15

User OS Interface – GUI

M. C. Escher

CSD 204, Spring 2018

Shashi Prabh

16

User OS Interface – GUI • User-friendly desktop metaphor interface – Usually mouse, keyboard, and monitor – Touchscreen is used to interact with mobile devices

• Icons represent files, programs, actions, … – Various mouse buttons over objects in the interface cause various actions • Provide information, options, execute function, open folder CSD 204, Spring 2018

Shashi Prabh

17

User OS Interface – GUI • Invented at Xerox PARC (1970) • Xerox Alto (73), Mac OS (80’s), Windows 1.0 (85)

• Many systems include both CLI and GUI interfaces – Linux, Solaris (Unix shells, GNOME, KDE) – MS Windows is GUI with “command shell”

– Apple Mac OS X has UNIX kernel underneath. Unix shells are available.

• Which kind of interface to use? CSD 204, Spring 2018

Shashi Prabh

wikipedia

18

System Calls

CSD 204, Spring 2018

Shashi Prabh

19

System Calls • Programming interface to the services provided by the OS – Typically written in a high-level language (C/C++)

– Assembly is also used if efficiency becomes crucial

• Mostly accessed by programs via a highlevel Application Program Interface (API) rather than direct system call use CSD 204, Spring 2018

Shashi Prabh

20

System Calls • Three most common APIs are – POSIX API for POSIX-based systems • Virtually all versions of UNIX, Linux & Mac OS X

– Win32 API for Windows – Java API for the Java virtual machine (JVM)

CSD 204, Spring 2018

Shashi Prabh

21

POSIX API: An Example • read – man read #include ssize_t read ( int fd, void * buf, size_t count )

• Why use APIs? – Portability, ease of use

CSD 204, Spring 2018

Shashi Prabh

22

System Calls: Example

System call sequence to copy the contents of one file to another

CSD 204, Spring 2018

Shashi Prabh

23

System Call Implementation • Typically, a number is associated with each system call • System-call interface maintains a table indexed according to these numbers – The system call interface invokes intended system call in OS kernel, and returns status of the system call and any return values

CSD 204, Spring 2018

Shashi Prabh

25

API – System Call – OS Relationship

CSD 204, Spring 2018

Shashi Prabh

26

System Call Implementation • Caller need not know anything about how is it implemented – Just needs to obey API and understand what OS will do as a result of the call

– Most details of OS interface hidden from programmer by API • Managed by run-time support library (set of functions built into libraries included with compiler)

CSD 204, Spring 2018

Shashi Prabh

27

Standard C Library Example (Linux) • C program invoking printf() library call, which eventually makes write() system call

CSD 204, Spring 2018

Shashi Prabh

28

System Call Parameter Passing • Often, more information is required than simply the identity of desired system call – Exact type and amount of information vary according to OS and call ssize_t read ( int fd, void * buf, size_t count )

CSD 204, Spring 2018

Shashi Prabh

29

System Call Parameter Passing • Three general methods used to pass parameters to the OS – Pass the parameters in registers (Simplest) • Used by Linux if at-most 5 parameters

– But possibly more parameters than registers can happen

– Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register • This approach taken by Linux and Solaris CSD 204, Spring 2018

Shashi Prabh

30

Parameter Passing via Table

CSD 204, Spring 2018

Shashi Prabh

31

System Call Parameter Passing –

Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system

• Block and stack methods do not limit the number or length of parameters being passed

CSD 204, Spring 2018

Shashi Prabh

32

Types of System Calls • Process control – end, abort – load, execute – create process, terminate process – get process attributes, set process attributes – wait for time

– wait event, signal event – allocate and free memory

CSD 204, Spring 2018

Shashi Prabh

33

Types of System Calls • File management

• Device management

– create file, delete file

– request device, release device

– open, close file – read, write, reposition

– read, write, reposition

– get and set file

– get device attributes,

set device attributes

attributes

– logically attach or detach devices CSD 204, Spring 2018

Shashi Prabh

34

Types of System Calls • Information maintenance

• Communications – create, delete

– get time or date, set

communication

time or date

connection

– get system data, set

– send, receive messages

system data

– transfer status

– get and set process,

information

file, or device

– attach and detach

attributes CSD 204, Spring 2018

remote devices Shashi Prabh

35

Examples of System Calls

CSD 204, Spring 2018

Shashi Prabh

36

Example: MS-DOS • Single-tasking • Shell is invoked when system boots • Simple method to run program, no process created, single memory space

• Loads program into memory, overwriting almost all of the command interpreter • On program exit, shell is reloaded CSD 204, Spring 2018

Shashi Prabh

37

FreeBSD: Running Multiple Programs • Unix variant, Multitasking • Upon user login user’s choice of shell is invoked • Shell executes fork() system call to create process and then exec() to load program into process – Shell either waits for the process to terminate or continues – Process terminates by calling exit() • Exits with 0 if no error or > 0 if error CSD 204, Spring 2018

Shashi Prabh

38

System Programs • System programs provide a convenient environment for program development and execution. – File manipulation and modification

– Status information – Programming language support

– Program loading and execution – Communications – Application programs CSD 204, Spring 2018

Shashi Prabh

39

Operating System Design and Implementation • Design and Implementation of OS not “solvable”, but some approaches have proven successful • Internal structure of different Operating Systems can vary widely

CSD 204, Spring 2018

Shashi Prabh

44

Operating System Design and Implementation (Cont.) • Start by defining goals and specifications – Affected by choice of hardware, type of system

• User goals and System goals – User goals – OS should be convenient to use, easy to learn, reliable, safe, and fast

– System goals – OS should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient CSD 204, Spring 2018

Shashi Prabh

45

Operating System Design and Implementation (Cont.) • Important principles – Policy: What will be done? – Mechanism: How to do it?

• The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later – CPU scheduling example

• High level language is used primarily CSD 204, Spring 2018

Shashi Prabh

46

Operating System Design and Implementation (Cont.) • Fred Brooks, “The mythical man month”

Dilbert by Scott Adams CSD 204, Spring 2018

Shashi Prabh

47

Operating System Structures • Monolithic – not desirable • Modular – How are the modules interconnected?

CSD 204, Spring 2018

Shashi Prabh

48

Simple Structure: MS-DOS • Written to provide the most functionality in the least space – Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated – Not portable since

implemented in Intel 8088 assembly language Layered Structure CSD 204, Spring 2018

Shashi Prabh

49

Layered Approach • OS is divided into a number of layers (levels), each built on top of lower layers. – The bottommost layer

• With modularity, layers are selected such that each uses functions and services of only lowerlevel layers

(0), is the hardware; the highest layer (N) is the user interface.

CSD 204, Spring 2018

Shashi Prabh

50

UNIX • Limited by hardware functionality, the original version had limited structuring. • The UNIX OS consists of two parts – Systems programs – The kernel • Consists of everything below the system-call

interface and above the physical hardware • Provides the file system, CPU scheduling, memory management, and other operating-system functions; a large number of functions for one level CSD 204, Spring 2018

Shashi Prabh

51

Traditional UNIX System Structure

CSD 204, Spring 2018

Shashi Prabh

52

Microkernel System Structure • Moves as much from the kernel into “user” space

• Communication takes place between user modules using message passing – MACH (CMU)

CSD 204, Spring 2018

Shashi Prabh

53

Microkernel System Structure • Pros – Easier to extend a microkernel – Easier to port the operating system to new architectures – More reliable (less code runs in kernel mode) – More secure

• Cons – Performance overhead of user space to kernel space communication CSD 204, Spring 2018

Shashi Prabh

54

Modules • Modern OSes implement kernel modules – Object-oriented approach – Each core component is separate – Each talks to the others over known interfaces – Each is loadable as needed within the kernel

CSD 204, Spring 2018

Shashi Prabh

55

Mac OS X Structure • Mach: memory management, support for RPCs and IPCs, thread scheduling. • BSD: CLI, networking and file systems, POSIX APIs including Pthreads.

• I/O kit: development of device drivers • Kernel extensions: dynamically loadable modules

CSD 204, Spring 2018

Shashi Prabh

56

Virtual Machines • A virtual machine (VM) takes the layered approach to its logical conclusion. – It treats hardware and the operating system kernel as though they were all hardware.

• VMs provide interface identical to the underlying bare hardware. • Host OS creates the illusion that a process has its own processor and (virtual memory) • Each guest is provided with a virtual copy of underlying computer. CSD 204, Spring 2018

Shashi Prabh

58

VMware Architecture

CSD 204, Spring 2018

Shashi Prabh

65

The Java Virtual Machine

CSD 204, Spring 2018

Shashi Prabh

66

Android • Dalvik is used by JAVA-based applications developed using Android API • Kernel includes power management

CSD 204, Spring 2018

Shashi Prabh

67

Operating System Debugging • Debugging is finding and fixing errors, or bugs • Kernighan’s Law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

CSD 204, Spring 2018

Shashi Prabh

68

Operating System Debugging • OSes generate log files containing error information • Failure of an application can generate core dump file capturing memory of the process

• Operating system failure can generate crash dump file containing kernel memory • Beyond crashes, performance tuning can optimize system performance and remove bottlenecks CSD 204, Spring 2018

Shashi Prabh

69

DTrace & SystemTap • DTrace & SystemTap are designed to run on production systems – Probes fire when code is executed, capturing state data and sending it to consumers of those probes CSD 204, Spring 2018

Shashi Prabh

70

Operating System Generation • Operating systems are designed to run on any of a class of machines; the system must be configured for each specific computer site • SYSGEN program obtains information concerning the specific configuration of the hardware system – Compilation vs customization

CSD 204, Spring 2018

Shashi Prabh

71

System Boot • Booting – starting a computer by loading the kernel • Operating system must be made available to hardware so hardware can start it • Small piece of code – bootstrap loader (bootloader), locates the kernel, loads it into memory, and starts it – Modern general purpose systems use two-step booting

– LILO, GRUB, NTLDR, boot.efi CSD 204, Spring 2018

Shashi Prabh

72

System Boot • On power-up, the instruction register is loaded with a predefined memory location – At that location is the initial bootstrap program (firmware), stored in ROM

– Does POST, initializes the system, starts running the kernel or passes control to another bootlaoder (e.g., GRUB) which can traverse file system and load the kernel

• Some systems, such as cellular phones, store the entire OS in ROM CSD 204, Spring 2018

Shashi Prabh

73

• Chapter summary – OS Services, user interfaces, system calls, system programs, OS design, OS structures, virtualization, debugging

• Reading assignment: Chapter 2 • Pre-reading: Chapter 3

CSD 204, Spring 2018

Shashi Prabh

75