CS330 Operating Systems and Lab

1. Spring 2009 Instructor : Insik Shin CS330 Operating Systems and Lab

2. Announcement • Lectures • Time : Tues & Thurs, 16:00-17:15 • Place : E3-1 #2443 (Lecture Room #3) • Textbook • Operating Systems Concept 8th edition • Course webpage http://cps.kaist.ac.kr/courses/2009_cs330/

3. Course Goals • CS330 Operating Systems and Lab • Operating system concepts • Programming skills

4. 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

5. Course Topics • Threads & Processes • Concurrency & Synchronization • Scheduling • Virtual Memory • I/O • File Systems • Non-traditional operating systems

6. Course Goals • Programming skills • Teach you how to deal with larger software systems • Programming assignments much larger than many other courses • Many people will consider this course very hard

7. Programming Assignments • 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

8. Programming Assignments • Implement projects in groups of up to 2 people • Project Guide Sections by TA • First section next Thursday (Feb. 12th) • Right after class ?

9. Schedule

10. 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, outlined in document and presented in demo • Plagiarism • We will be very serious on it • Cite any code that inspired your code

11. People • Instructor : Prof. Insik Shin (신인식) • Teaching Assistants (TA) • JeahoWhang (황재호) • Youngsik Lee (이영식) • Jaehong Kim (김재홍) • JungsangAhn (안정상) • Hosung Park (박호성) • HunseungChwa (좌훈승)

12. 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 systems

13. What is an operating system? • Layer between applications and hardware • Makes hardware useful to the programmer • Provides abstractions for applications • Manages and hides details of hardware • Accesses hardware through low-level interfaces unavailable to applications

14. Operating System Goals • Operating system goals: • Execute user programs and make solving user problems easier • Make the computer system convenient to use • Use the computer hardware in an efficient manner

15. Operating System Definition • 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 prevent errors and improper use of the computer

16. Operating System Definition (Cont) • No universally accepted definition • “Everything a vendor ships when you order an operating system” is good approximation • But varies wildly • “The one program running at all times on the computer” is the kernel. Everything else is either a system program (ships with the operating system) or an application program

17. Computer Systems - Components

18. Computer System Structure • Computer system can be divided into four components • 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 applications and users

19. Four Components of Computer Systems

20. Computer System Organization

21. Computer Startup • bootstrap programis loaded at power-up or reboot • Typically stored in ROM or EEPROM, generally 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

22. 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 system call • CPU, when interrupted, transfers control to interrupt service routines (ISR), and resumes its interrupted computation when ISR is done

23. Interrupt Timeline

24. Common Functions of Interrupts • Interrupt transfers control to the interrupt service routine generally, through the interruptvector, 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 interrupt • 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 request

25. Interrupt-driven I/O Operation • I/O is an important part of OS, since it is critical to reliability 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/O • DD loads proper registers within DC • DC looks at the registers and determines what to do (i.e., read a character from the keyboard) • DC moves data from the device to its local buffer • Once completion, DC informs DD via an interrupt • DD returns the control to the OS, possibly returning the data (or status)

26. Operating-System Operations • OS and users share h/w and s/w resources • 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 programs

27. Dual-Mode Operation • Dual-mode operation allows OS to protect itself and other system components • 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

28. Transition from User to Kernel Mode • Transition through systems calls

29. Life Cycle • At system boot time, hardware starts in kernel mode • OS is then loaded and starts user applications 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

30. 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 Windows 2000 and higher, Linux and Solaris for x86) • Any illegal instruction violating mode causes the hardware to trap to the operating system

31. A View of Operating System Services

32. 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 error) • 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 particular interest. Obviously, programs need to read and write files and directories, create and delete them, search them, list file Information, permission management.

33. Operating System Services (Cont) • 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) • 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 • 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

34. Operating System Services (Cont) • Another set of OS functions exists for ensuring 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 networked computer system may want to control use of that information, concurrent processes should not interfere with each other

35. 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 Application 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?

36. Example of System Calls Copy

37. 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 Application 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?

38. Example of Standard API • Consider the ReadFile() function in the Win32 API—a function 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

39. System Call Implementation • 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 libraries included with compiler)

40. API – System Call – OS Relationship

41. System Call Parameter Passing • Often, more information is required than simply identity 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 address of block passed as a parameter in a register • This approach taken by Linux and Solaris • Parameters placed, or pushed, onto the stackby 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

42. Parameter Passing via Table

43. Types of System Calls • Process control • File management • Device management • Information maintenance • Communications • Protection