Presentation is loading. Please wait.

Presentation is loading. Please wait.

CENG334 Introduction to Operating Systems 1 Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:

Similar presentations


Presentation on theme: "CENG334 Introduction to Operating Systems 1 Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:"— Presentation transcript:

1 CENG334 Introduction to Operating Systems 1 Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: Operating System Overview Topics Brief History OS Services System calls Basic Operation OS structures Some of the following slides are adapted from Matt Welsh, Harvard Univ.

2 2 In the Beginning... There was no OS – just libraries Computer only ran one program at a time, so no need for an OS Programming through wiring.. Harvard Mark I, 1944 IBM 360, 1960's ENIAC, 1945

3 3 In the Beginning... There was no OS – just libraries Computer only ran one program at a time, so no need for an OS And then there were batch systems Programs printed on stacks of punchhole cards OS was resident in a portion of machine memory When previous program was finished, OS loaded next program to run

4 4 Punch Card

5 5 In the Beginning... There was no OS – just libraries Computer only ran one program at a time, so no need for an OS And then there were batch systems Programs printed on stacks of punchhole cards OS was resident in a portion of machine memory When previous program was finished, OS loaded next program to run

6 6 In the Beginning... There was no OS – just libraries Computer only ran one program at a time, so no need for an OS And then there were batch systems Programs printed on stacks of punchhole cards OS was resident in a portion of machine memory When previous program was finished, OS loaded next program to run Disk spooling Disks were much read stack onto disk while previous program is running With multiple programs on disk, need to decide which to run next! But, CPU still idle while program accesses a peripheral (e.g., tape or disk!)‏

7 7 Multiprogramming To increase system utilization, multiprogramming OS’s were invented keeps multiple runnable jobs loaded in memory at once Overlaps I/O of a job with computing of another While one job waits for I/O to compile, CPU runs instructions from another job To benefit, need asynchronous I/O devices need some way to know when devices are done performing I/O Goal: optimize system throughput perhaps at the cost of response time… Dennis Ritchie and Ken Thompson at a PDP11, 1971

8 8 Timesharing To support interactive use, timesharing OS's were created multiple terminals connected to one machine each user has illusion of entire machine to him/herself optimize response time, perhaps at the cost of throughput Timeslicing divide CPU fairly among the users if job is truly interactive (e.g. editor), then can switch between programs and users faster than users can generate load MIT Multics (mid-1960’s) was the first large timeshared system nearly all modern OS concepts can be traced back to Multics

9 9 Personal Computing Totally changed the computing industry. CP/M: First personal computer OS IBM needed OS for their PCs, CP/M behind schedule Bill Gates to the rescue: Bought 86-DOS and made MS-DOS DOS is basically a subroutine library! Many popular personal computers follow Apple, Commodore, TRS-80, TI 99/4, Atari, etc... Bill Gates and Paul Allen, c.1975 Commodore VIC-20 IBM PC, 1981 Apple LISA, 1983 Apple I, 1976

10 10

11 11 Parallel Computing and Clusters High-end scientific apps want to use many CPUs at once Parallel processing to crunch on enormous data sets Need OS and language primitives for dividing program into parallel activities Need OS primitives for fast communication between processors degree of speedup dictated by communication/computation ratio Many kinds of parallel machines: SMPs: symmetric multiprocessors – several CPUs accessing the same memory MPPs: massively parallel processors – each CPU may have its own memory Clusters: connect a lot of commodity machines with a fast network

12 12 Distributed OS Goal – Make use of geographically distributed resources workstations on a LAN servers across the Internet Supports communication between applications interprocess communication (on a single machine): message passing and shared memory networking procotols (across multiple machines): TCP/IP, Java RMI,.NET SOAP “The Grid”,.NET, and OGSA Idea: Seamlessly connect vast computational resources across the Internet

13 13 Embedded OS The rise of tiny computers everywhere – ubiquitous computing Processor cost low enough to embed in many devices PDAs, cell phones, pagers,... How many CPUs are in your car? On your body right now? Gets more interesting with ubiquitous networking! Wireless networks becoming pervasive Sensor networks are an exciting new direction here Little “motes” with less 4KB of RAM, some sensors, and a radio Typically very constrained hardware resources slow processors very small amount of memory (e.g. 8 MB)‏ no disk – but maybe quasi-permanent storage such as EEPROM

14 14 Operating System Overview User application Kernel Memory management Disk I/O Process management Device drivers Filesystem TCP/IP stack Accounting CPU support Protection boundary Hardware/software interface

15 15 Operating System Services (What things does the OS do?)‏ Services that (more-or-less) map onto components Program execution How do you execute concurrent sequences of instructions? I/O operations Standardized interfaces to extremely diverse devices File system manipulation How do you read/write/preserve files? Looming concern: How do you even find files??? Communications Networking protocols/Interface with CyberSpace? User interface- Almost all operating systems have a user interface (UI)‏ Varies between Command-Line (CLI), Graphics User Interface (GUI), Batch Cross-cutting capabilities Error detection & recovery Resource allocation Accounting Protection

16 16 User Operating System Interface - CLI CLI allows direct command entry Sometimes implemented in kernel, sometimes by systems programs Sometimes multiple flavors implemented – shells Primarily fetches a command from user and executes it Sometimes commands built-in, sometimes just names of programs If the latter, adding new features doesn’t require shell modification

17 17 User Operating System Interface - GUI User-friendly desktop metaphor interface Usually mouse, keyboard, and monitor Icons represent files, programs, actions, etc Various mouse buttons over objects in the interface cause various actions provide information, options, execute function, open directory (known as a folder) Invented at Xerox PARC Many systems now include both CLI and GUI interfaces Microsoft Windows is GUI with CLI “command” shell Apple Mac OS X as “Aqua” GUI interface with UNIX kernel underneath and shells available Solaris is CLI with optional GUI interfaces (Java Desktop, KDE)

18 18 Xerox PARC Alto

19 19 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?

20 20 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

21 21 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)

22 22 API – System Call – OS Relationship

23 23 System Programs System programs provide a convenient environment for program development and execution. They can be divided into: File manipulation Status information File modification Programming language support Program loading and execution Communications Application programs Most users’ view of the operation system is defined by system programs, not the actual system calls

24 24 System Programs Provide a convenient environment for program development and execution Some of them are simply user interfaces to system calls; others are considerably more complex File management - Create, delete, copy, rename, print, dump, list, and generally manipulate files and directories Status information Some ask the system for info - date, time, amount of available memory, disk space, number of users Others provide detailed performance, logging, and debugging information Typically, these programs format and print the output to the terminal or other output devices Some systems implement a registry - used to store and retrieve configuration information

25 25 System Programs (cont’d)‏ File modification Text editors to create and modify files Special commands to search contents of files or perform transformations of the text Programming-language support - Compilers, assemblers, debuggers and interpreters sometimes provided Program loading and execution- Absolute loaders, relocatable loaders, linkage editors, and overlay- loaders, debugging systems for higher-level and machine language Communications - Provide the mechanism for creating virtual connections among processes, users, and computer systems Allow users to send messages to one another’s screens, browse web pages, send electronic-mail messages, log in remotely, transfer files from one machine to another

26 26 Memory Operating System operation The OS kernel is just a bunch of code that sits around in memory, waiting to be executed OS Kernel (device drivers, file systems, virtual memory, etc.)‏ Emacs Firefox xmms sshd

27 27 Operating System operation The OS kernel is just a bunch of code that sits around in memory, waiting to be executed OS is triggered in two ways: system calls and hardware interrupts System call: Direct “call” from a user program For example, open() to open a file, or exec() to run a new program Hardware interrupt: Trigger from some hardware device For example, when a disk block has been read or written OS Kernel (device drivers, file systems, virtual memory, etc.)‏ Memory Emacs Firefox xmms sshd System call (open network socket)‏ Interrupt (disk block read)‏

28 28 Interrupts – a primer An interrupt or exception is a signal that causes the CPU to jump to a pre-defined instruction – called the interrupt or exception handler Interrupt can be caused by hardware or software Hardware interrupt examples Timer interrupt (periodic “tick” from a programmable timer) Device interrupts e.g., Disk will interrupt the CPU when an I/O operation has completed Software interrupt examples Division by zero error Access to a bad memory address Intentional software interrupt – e.g., x86 “INT” instruction Can be used to trap from user program into the OS kernel! Why might this be useful?

29 29 Interrupt handler example Interrupt handler table Interrupt handler for interrupt 4 Interrupt handler for interrupt 5 1) OS fills in interrupt handler table (usually at boot time) ‏ 2) Interrupt occurs – e.g., hardware signal !!! 3) CPU state saved to stack

30 30 Interrupt handler for interrupt 4 Interrupt handler for interrupt 4 Interrupt handler example Interrupt handler table Interrupt handler for interrupt 5 1) OS fills in interrupt handler table (usually at boot time) ‏ 2) Interrupt occurs – e.g., hardware signal !!! 3) CPU state saved to stack 4) CPU consults interrupt table and invokes appropriate handler

31 31 Control Flow inst 1 inst 2 inst 3 … inst n Processors do only one thing: From startup to shutdown, a CPU simply reads and executes (interprets) a sequence of instructions, one at a time This sequence is the CPU’s control flow (or flow of control) Physical control flow Time

32 32 Altering the Control Flow Up to now: two mechanisms for changing control flow: Jumps and branches Call and return Both react to changes in program state Insufficient for a useful system: Difficult to react to changes in system state data arrives from a disk or a network adapter instruction divides by zero user hits Ctrl-C at the keyboard System timer expires System needs mechanisms for “exceptional control flow”

33 33 Exceptional Control Flow Exists at all levels of a computer system Low level mechanisms Exceptions change in control flow in response to a system event (i.e., change in system state) Combination of hardware and OS software Higher level mechanisms Process context switch Signals Nonlocal jumps: setjmp()/longjmp() Implemented by either: OS software (context switch and signals) C language runtime library (nonlocal jumps)

34 34 Exceptions An exception is a transfer of control to the OS in response to some event (i.e., change in processor state) Examples: div by 0, arithmetic overflow, page fault, I/O request completes, Ctrl-C User ProcessOS exception exception processing by exception handler return to I_current return to I_next abort event I_current I_next

35 n-1 Interrupt Vectors Each type of event has a unique exception number k k = index into exception table (a.k.a. interrupt vector) Handler k is called each time exception k occurs Exception Table code for exception handler 0 code for exception handler 1 code for exception handler 2 code for exception handler n-1... Exception numbers

36 36 Asynchronous Exceptions (Interrupts) Caused by events external to the processor Indicated by setting the processor’s interrupt pin Handler returns to “next” instruction Examples: I/O interrupts hitting Ctrl-C at the keyboard arrival of a packet from a network arrival of data from a disk Hard reset interrupt hitting the reset button Soft reset interrupt hitting Ctrl-Alt-Delete on a PC

37 37 Synchronous Exceptions Caused by events that occur as a result of executing an instruction: Traps Intentional Examples: system calls, breakpoint traps, special instructions Returns control to “next” instruction Faults Unintentional but possibly recoverable Examples: page faults (recoverable), protection faults (unrecoverable), floating point exceptions Either re-executes faulting (“current”) instruction or aborts Aborts unintentional and unrecoverable Examples: parity error, machine check Aborts current program

38 38 Trap Example: Opening File User calls: open(filename, options) Function open executes system call instruction int OS must find or create file, get it ready for reading or writing Returns integer file descriptor 0804d070 : d082:cd 80 int $0x80 804d084:5b pop %ebx... User ProcessOS exception open file returns int pop

39 39 Fault Example: Page Fault User writes to memory location That portion (page) of user’s memory is currently on disk Page handler must load page into physical memory Returns to faulting instruction Successful on second try int a[1000]; main () { a[500] = 13; } 80483b7:c d d movl $0xd,0x8049d10 User ProcessOS exception: page fault Create page and load into memory returns movl

40 40 Fault Example: Invalid Memory Reference Page handler detects invalid address Sends SIGSEGV signal to user process User process exits with “segmentation fault” int a[1000]; main () { a[5000] = 13; } 80483b7:c e d movl $0xd,0x804e360 User ProcessOS exception: page fault detect invalid address movl signal process

41 41 Exception Table IA32 (Excerpt) Exception NumberDescriptionException Class 0Divide errorFault 13General protection faultFault 14Page faultFault 18Machine checkAbort OS-definedInterrupt or trap 128 (0x80)System callTrap OS-definedInterrupt or trap Check pp. 183:

42 42 Protection A major job of the OS is to enforce protection Prevent malicious or buggy programs from: Allocating too many resources (denial of service)‏ Corrupting or overwriting shared resources (files, shared memory, etc.)‏ Prevent different users, groups, etc. from: Accessing or modifying private state (files, shared memory, etc.)‏ Killing each other's processes How does the OS enforce protection boundaries?

43 43 Enforcing Resource Limits The OS limits what resources user programs can access For example, Emacs can't modify memory in use by Mozilla. xmms can't hog the CPU and prevent other programs from running. One user cannot read/write another user's files (Unless permissions are set appropriately)‏ How does the OS enforce these limits? This implies that regular user programs cannot “break out” of these limits! We'll see how on the next slide. A lot of viruses, worms, etc. exploit security holes in the OS Overrunning a memory buffer in the kernel can give a non-root process root privileges Kernel code needs to be rock solid in order to be secure!!!

44 44 User mode vs. kernel mode What makes the kernel different from user programs? Kernel can execute special privileged instructions Examples of privileged instructions: Access I/O devices Poll for IO, perform DMA, catch hardware interrupt Manipulate memory management Set up page tables, load/flush the TLB and CPU caches, etc. Configure various “mode bits” Interrupt priority level, software trap vectors, etc. Call halt instruction Put CPU into low-power or idle state until next interrupt These are enforced by the CPU hardware itself. CPU has at least two protection levels: Kernel mode and user mode CPU checks current protection level on each instruction What happens if user program tries to execute a privileged instruction?

45 45 Web surfing homework for Thursday! Learn More about XEROX PARC What else had they invented More about Ken Thomson and Dennis Ritchie What are they known for More about Microsoft How did MS-DOS become so successful? More about Apple What’s the relation between XEROX PARC GUI and Apple GUI? Use Wikipedia, and google the web..


Download ppt "CENG334 Introduction to Operating Systems 1 Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:"

Similar presentations


Ads by Google