CS330 Operating Systems and Lab

Spring 2009

Instructor : Insik Shin

Announcement

Lectures Time : Tues & Thurs, 16:00-17:15 Place : E3-1 #2443 (Lecture Room #3)

Textbook Operating Systems Concept 8th edition

Course webpagehttp://cps.kaist.ac.kr/courses/2009_cs330/

Course Goals

CS330 Operating Systems and Lab

Operating system concepts

Programming skills

Course Goals

Operating system concepts

Introduce you to operating system concepts▪ Hard to use a computer without interacting with

OS▪ Understanding the OS makes you a more effective

programmer

Cover important systems concept in general▪ Caching, concurrency, memory management, I/O

Course Topics

Threads & Processes Concurrency & Synchronization Scheduling Virtual Memory I/O File Systems Non-traditional operating systems

Course Goals

Programming skills

Teach you how to deal with larger soft-ware systems▪ Programming assignments much larger than

many other courses▪ Many people will consider this course very

hard

Programming Assign-ments

Implement parts of Pintos operating systems Built for x86 hardware, you will use

hardware emulator Four implementation projects:

Threads User programs Virtual memory File systems

Programming Assign-ments

Implement projects in groups of up to 2 people

Project Guide Sections by TA First section next Thursday (Feb. 12th) Right after class ?

Schedule

Week

Lecture Project Week Lecture Project

1 Intro. 9 Virtual mem-ory

3

2 OS Structures 10 File systems 3

3 Process 0 11 File systems 3

4 Threads 1 12 Mass storages 3

5 CPU schedul-ing

1 13 I/O systems 4

6 Synchroniza-tion

2 14 Real-time sys-tems

4

7 Deadlocks 2 15 Distributed systems

4

8 Memory 3 16 Security

Grading

Final grade 50% : midterm and final exams▪ (midterm + final) /2 or (midterm+2*final) /3

50% : projects▪ how requirements are fulfilled▪ how good/creative design is employed, out-

lined in document and presented in demo Plagiarism

We will be very serious on it Cite any code that inspired your code

People

Instructor : Prof. Insik Shin (신인식 )

Teaching Assistants (TA) Jeaho Whang (황재호 ) Youngsik Lee (이영식 ) Jaehong Kim (김재홍 ) Jungsang Ahn (안정상 ) Hosung Park (박호성 ) Hunseung Chwa (좌훈승 )

Instructor

Insik Shin BS from Korea Univ. & MS from Stanford Univ. Ph. D. from University of Pennsylvania, 2006 Post-doctoral research in Sweden & at UIUC Assistant professor at KAIST from 2008

Interested in operating systems, real-time embedded systems, and cyber-physical sys-tems

What is an operating system? Layer between applications and hard-

ware

Makes hardware useful to the pro-grammer

Provides abstractions for applications Manages and hides details of hardware Accesses hardware through low-level inter-

faces unavailable to applications

Operating System Goals

Operating system goals:

Execute user programs and make solv-ing user problems easier

Make the computer system convenient to use

Use the computer hardware in an effi-cient manner

Operating System Defi-nition

OS is a resource allocator Manages all resources Decides between conflicting requests for

efficient and fair resource use OS is a control program

Controls execution of programs to pre-vent errors and improper use of the computer

Operating System Definition (Cont)

No universally accepted definition “Everything a vendor ships when you

order an operating system” is good ap-proximation But varies wildly

“The one program running at all times on the computer” is the kernel. Every-thing else is either a system program (ships with the operating system) or an application program

Computer Systems - Compo-nents

Computer System Struc-ture Computer system can be divided into four compo-

nents

Users▪ People, machines, other computers

Hardware – provides basic computing resources▪ CPU, memory, I/O devices

Application programs – define the ways in which the system resources are used to solve the computing problems of the users▪ Word processors, compilers, web browsers, database systems, video

games Operating system▪ Controls and coordinates use of hardware among various applica-

tions and users

Four Components of Computer Systems

Computer System Orga-nization

Computer Startup

bootstrap program is loaded at power-up or reboot Typically stored in ROM or EEPROM, gen-

erally known as firmware Initializes all aspects of system Loads operating system kernel and

starts execution OS then starts running the first process

(“init”) and wait for some event to occur

Communication over Events

Interrupt Hardware and software have their own

events and signal the occurrence of the events to the CPU by an interrupt ▪ H/W sends a signal to the CPU, thru the system

bus▪ S/W executes a special operation called a sys-

tem call

CPU, when interrupted, transfers control to inter-rupt service routines (ISR), and resumes its inter-rupted computation when ISR is done

Interrupt Timeline

Common Functions of Inter-rupts

Interrupt transfers control to the interrupt service routine generally, through the interrupt vector, which contains the addresses of all the service routines

Interrupt architecture must save the address of the interrupted instruction

Incoming interrupts are disabled while another interrupt is being processed to prevent a lost in-terrupt

A trap (or an exception) is a software-generated interrupt caused either by an error (i.e., divide-by-zero or invalid memory access) or a user re-quest

Interrupt-driven I/O Opera-tion

I/O is an important part of OS, since it is critical to re-liability and performance

Each I/O device has its own device controller (DC), and OS has a device driver (DD) for each controller

Interrupt-driven I/O1. DD loads proper registers within DC2. DC looks at the registers and determines what to

do (i.e., read a character from the keyboard)3. DC moves data from the device to its local buffer4. Once completion, DC informs DD via an interrupt5. DD returns the control to the OS, possibly return-

ing the data (or status)

Operating-System Oper-ations OS and users share h/w and s/w re-

sources

Users could cause problems, such as infinite loop or modifying other user programs or OS

Needs to protect OS and users from erroneous (or malicious) user pro-grams

Dual-Mode Operation

Dual-mode operation allows OS to protect itself and other system com-ponents User mode and kernel mode Mode bit provided by hardware▪ Provides ability to distinguish when system is

running user code or kernel code▪ Some instructions designated as privileged,

only executable in kernel mode▪ System call changes mode to kernel, return

from call resets it to user

Transition from User to Ker-nel Mode

Transition through systems calls

Life Cycle

At system boot time, hardware starts in kernel mode

OS is then loaded and starts user applica-tions in user mode

Whenever a trap or interrupt occurs, hardware switches to kernel mode Whenever OS gains control, it is in kernel mode

The system switches to user mode before passing control to a user program

Hardware Support on Dual Mode

Intel 8088 architecture (MS-DOS) no support on mode bit (no dual support)

Recent Intel CPU (i.e., Pentium) Provides dual-mode operations (with Win-

dows 2000 and higher, Linux and Solaris for x86)

Any illegal instruction violating mode causes the hardware to trap to the operat-ing system

A View of Operating System Services

Operating System Services (Cont)

User interface - Almost all operating systems have a user interface (UI) Varies between Command-Line (CLI), Graphics User Interface

(GUI), Batch Program execution - The system must be able to load a

program into memory and to run that program, end execution, either normally or abnormally (indicating er-ror)

I/O operations - A running program may require I/O, which may involve a file or an I/O device

File-system manipulation - The file system is of partic-ular interest. Obviously, programs need to read and write files and directories, create and delete them, search them, list file Information, permission manage-ment.

Operating System Services (Cont)

Communications – Processes may exchange in-formation, 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)

Error detection – OS needs to be constantly aware of possible errors May occur in the CPU and memory hardware, in I/O de-

vices, in user program For each type of error, OS should take the appropriate

action to ensure correct and consistent computing Debugging facilities can greatly enhance the user’s and

programmer’s abilities to efficiently use the system

Operating System Services (Cont)

Another set of OS functions exists for ensur-ing the efficient operation of the system itself via resource sharing Resource allocation - When multiple

users or multiple jobs running concurrently, resources must be allocated to each of them

Accounting - To keep track of which users use how much and what kinds of computer resources

Protection and security - The owners of information stored in a multiuser or net-worked computer system may want to con-trol use of that information, concurrent pro-cesses should not interfere with each other

System Calls

Programming interface to the services provided by the OS

Typically written in a high-level language (C or C++)

Mostly accessed by programs via a high-level Applica-tion Program Interface (API) rather than direct system call use

Three most common APIs are Win32 API for Windows, POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and Java API for the Java virtual machine (JVM)

Why use APIs rather than system calls?

Example of System Calls

Copy

System Calls

Programming interface to the services provided by the OS

Typically written in a high-level language (C or C++)

Mostly accessed by programs via a high-level Applica-tion Program Interface (API) rather than direct system call use

Three most common APIs are Win32 API for Windows, POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and Java API for the Java virtual machine (JVM)

Why use APIs rather than system calls?

Example of Standard API Consider the ReadFile() function in the Win32 API—a func-

tion for reading from a file

A description of the parameters passed to ReadFile() HANDLE file—the file to be read LPVOID buffer—a buffer where the data will be read into and written

from DWORD bytesToRead—the number of bytes to be read into the buffer LPDWORD bytesRead—the number of bytes read during the last read LPOVERLAPPED ovl—indicates if overlapped I/O is being used

System Call Implemen-tation Typically, a number 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

The caller need know nothing about how the system call is implemented Just needs to obey API and understand what OS will do as a

result call Most details of OS interface hidden from programmer by

API ▪ Managed by run-time support library (set of functions built into li-

braries included with compiler)

API – System Call – OS Rela-tionship

System Call Parameter Passing Often, more information is required than simply iden-

tity of desired system call Exact type and amount of information vary according to OS

and call

Three general methods used to pass parameters to the OS Simplest: pass the parameters in registers▪ In some cases, may be more parameters than registers

Parameters stored in a block, or table, in memory, and ad-dress of block passed as a parameter in a register ▪ This approach taken by Linux and Solaris

Parameters placed, or pushed, onto the stack by the pro-gram and popped off the stack by the operating system

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

Parameter Passing via Table

Types of System Calls

Process control File management Device management Information maintenance Communications Protection