spring 2009 instructor : insik shin. lectures time : tues & thurs, 16:00-17:15 place : e3-1...
Post on 22-Dec-2015
222 views
TRANSCRIPT
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