1 / 67

Today

Today. Welcome Reading: Chapter 1 MOS P1: Administrivia Gentle Introduction: History, OS Roles, H/W basics Break: Meet your classmates, form a team 2-3 P2: Systems structures, OS Components . What To Do This Week. 1 . Read Chapter 1, 2 of MOS 2. Look at the course web

mandy
Download Presentation

Today

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Today Welcome Reading: Chapter 1 MOS P1: Administrivia Gentle Introduction: History, OS Roles, H/W basics Break: Meet your classmates, form a team 2-3 P2: Systems structures, OS Components

  2. What To Do This Week • 1. Read Chapter 1, 2 of MOS • 2. Look at the course web • 3. Assess your comfort zone for taking the course

  3. CSci 5103Operating Systems Admin, Introduction, History

  4. Course Mechanics • Welcome to CSci 5103! • me: Jon Weissman, Assoc. Professor CS • (Hrs T/Th 1-2, 4-225F CSE) • interests: distributed and parallel systems • TA: Andy Exley (Hrs TBD, 2-209 CSE) • This is a grad-level OS course suitable for grad students and highly motivated senior undergraduates

  5. Compressed Summer Schedule This is normally a 14 week course compressed into 6 weeks! Lose 1 project, and some content, but not too much Made worse by my travel schedule ~ 5 taped lectures, may be able to watch them live on Fri We’ll see how this all works out … Go to Web schedule

  6. Lectures 3 hrs, 20 minutes is looonnnng Decompose into two 1.5 hrs segments with a break of ~15 minutes in-between Help with discussions

  7. Course Mechanics (con’t) • It is not a course for someone that wishes to “dabble” in OS • It will be hard work … but it will be fun work  • Prereq: undergraduate OS (4061 or equiv.) • Soft prereq: • Computer Org/Architecture (2021 or eq.) • Knowledge of C/C++, Unix, and debugging is crucial (get to know gdb or ddd)

  8. Course Mechanics (cont’d) • Website: http://www.itlabs.umn.edu/classes/ • Summer-2010/csci5103 • check it out – read announcements daily • start by looking at schedule, syllabus, impt. dates • Books • Tannenbaum MOS 3erdedition; equivalent books include S&G 8th edition • On-line materials including research papers

  9. Course Mechanics (cont’d) • Grades • 3 programming projects, 2 exams (mid + final), 3 written homeworks • Late work – 1 proj/1 hw, 10% penalty, 1 extra day • All projects will be groups; all get same score • Regrading – within 1 week window

  10. Course Mechanics (cont’d) • Working together • Great idea … but be careful • Team projects require a necessary collaboration. No barriers on this collaboration. • Homeworks are done individually! • Can discuss meaning of questions or issues, but should not share code, solutions. • If you utter “how did you do it to a classmate?” or “does this look right” or “why doesn’t this code work?” – that’s too much collaboration

  11. Syllabus • Course Introduction • Processes/Threads • Scheduling • Synchronization/Deadlock • Memory Management and Virtual Memory • Protection • File Systems and I/O • Distributed (File) Systems • OS Design • Hopefully we will get to all of this

  12. What do I need for this course? • Computer architecture • CPU, interrupts, I/O devices, protection • C/C++ and Unix comfort • Systems programming (e.g. 4061) is required • Experience with Unix debuggers is also helpful • Willingness to work hard • Systems is hard work … but your hard work will be rewarded. “No Pain No Gain”

  13. Course Materials for CSci 5103 • TanenbaumMOS 3erd edition, 2008 • source for most of the lecture content, but notall • he is “the man” • There will also be some papers to read, they will be posted soon

  14. Am I up to it? • If Chapter 1 has you worried, you may want to bail. • Also, can you parse this code? • #include <stdio.h> • #include <sys/types.h> • #include <sys/syscall.h> • // only works on pentium+ x86 – extended ASM • // access the pentium cycle counter • void access_counter(unsigned int *hi, unsigned int *lo) { • asm("rdtsc; movl %%edx,%0; movl %%eax,%1" /* Read cycle counter */ • : "=r" (*hi), "=r" (*lo) /* and move results to */ • : /* No input */ /* the two outputs */ • : "%edx", "%eax"); • }

  15. Or this? unsigned inttimediff(structtimeval before, structtimeval after) { unsigned int diff; diff = after.tv_sec - before.tv_sec; diff *= 1000000; diff += (after.tv_usec - before.tv_usec); return diff; }

  16. 4061 vs. 5103 • Small overlap in OS concepts • We’ll explore concepts in greater depth • 4061: locks, semaphores • 5103: how are they implemented • Focus is on the inside-view of the OS • How are things implemented INSIDE the OS • 4061: how can I manipulate processes? • 5103: how are processes implemented inside the kernel? • But will also refer to systems API at times

  17. Programming Projects Reflect the 5103 orientation Systems-programming is the focus of 4061 – how does one use OS facilities from the outside Our projects reflect inside perspective experiment with inside mechanisms, policies, and their effects – simulation kernel level experimentation possibly

  18. Questions?

  19. CSci 5103Operating Systems Introduction, History, and Overview

  20. What is an Operating System?

  21. What is an Operating System? • A program that acts as an intermediary between a “user” of a computer and the computer hardware. • 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. • What does efficient mean?

  22. User Applications virtual machine interface Operating System Architecture Operating Systems: The Big Picture • The operating system (OS) is the interface between user applications and the hardware. • An OS implements a virtual machine that is easier to program than the raw hardware • Example? physical machine interface

  23. Computer System Components • 1. Hardware – provides basic computing resources (CPU, memory, storage, I/O devices). • 2. Operating system – controls and coordinates the use of the hardware among the various application programs for the various users. • Applications programs – define the ways in which the system resources are used to solve the computing problems of the users (compilers, database systems, video games, …) 3a. Systems vs. Applications • 4. Users (people, programs, other computers).

  24. OS Facilities • Storage: primitives for files and virtual memory • control devices and provide for the “care and feeding” of the memory system hardware and peripherals • Protection and security • set boundaries that limit damage from faults and errors • establish user identities, priorities, and accountability • access control for logical and physical resources • Execution: primitives to create/execute programs • support an environment for developing/running apps • Communication: “glue” for programs to interact

  25. The Four Faces of Your Operating System • service provider (4061) • The OS exports commonly needed facilities with standard interfaces, so that programs can be simple and portable. Abstraction. • Examples? • executive/bureaucrat/juggler • The OS controls access to hardware, and allocates physical resources (memory, disk, CPU time) for the greatest good. Multiplexing. • Examples?

  26. The Four Faces of Your Operating System (cont’d) • caretaker • The OS monitors the hardware and intervenes to resolve exceptional conditions that interrupt smooth operation. Isolation. • Examples? • cop/security guard • The OS mediates access to resources and grants or denies each request. Protection. • Examples?

  27. Big Picture Questions • The basic issues/questions in this course are how to: • allocate memory and storage to multiple programs? • share the CPU among concurrently executing pgrams? • suspend and resume programs? • share data safely among concurrent activities? • protect one executing program’s storage from another? • protect the code that mediates access to resources? • allow programs to interact safely? Which SPEC categories does each belong to? storage, protection, execution, communication

  28. Big Picture Questions (cont’d) • The basic issues/questions in this course are how to: • allocate memory and storage to multiple programs? (S) • share the CPU among concurrently executing programs? (E) • suspend and resume programs? (E) • share data safely among concurrent activities? (C) • protect one executing program’s storage from another? (P) • protect the code that mediates access to resources? (P) • allow programs to interact safely? (C)

  29. User vs. System Goals • User goals – operating system should be convenient to use, easy to learn, reliable, safe, and fast. • System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient. • Which may be at odds?

  30. Studying Operating Systems • This course deals with “classical” operating systems issues: • the services and facilities • OS implementation on modern hardware; • (and architectural support) • the techniques used to implement software systems that are: • large and complex, long-lived and evolving, • concurrent, performance-critical.

  31. History: How did we get here? • Batch systems • Early computers were few in #, big, and very expensive, limited resources • Why only 1 program? • Users submit jobs (punch cards) to operators • User program read into memory and run, one at-a-time • Later they pick up output (core dump, correct results) • Multiprogrammed Batch • Several jobs are kept in memory simultaneously • What new OS facilities are needed?

  32. History: How did we get here? • Batch systems • Early computers were few in #, big, and very expensive • Users submit jobs (punch cards) to operators • User program read into memory and run, one at-a-time • Later they pick up output (core dump, correct results) • Multiprogrammed Batch • Several jobs are kept in memory simultaneously • CPU switching • Memory management • CPU scheduling

  33. How did we get here? (cont’d) • Multitasking (multi-user)-interactive • Jobs can reside on disk • What new OS facilities/features?

  34. How did we get here? (cont’d) • Multitasking (multi-user)-interactive • Jobs can reside on disk: introduced swapping and virtual memory • User/OS interaction: command-line (keyboard and terminal)

  35. How did we get here? (cont’d) power, real-time, reliability

  36. BREAK Meet your classmates Find teamates

  37. CSci 5103Operating Systems System structures: Hardware and OS

  38. A First Look at Some Key Concepts • kernel • What is it? • thread • What is it?

  39. A First Look at Some Key Concepts • kernel • The software component that controls the hardware directly, and implements the core privileged OS functions. • Modern hardware has features that allow the OS kernel to protect itself from untrusted user code.

  40. A First Look at Some Key Concepts • thread • An executing stream of instructions and its CPU register context.

  41. Key Concepts (cont’d) • virtual address space • What is it? • process • What is it?

  42. Key Concepts (cont’d) • virtual address space • An execution context for threads/processes that provides an independent name space for addressing code and data • process • An execution of a program, consisting of a virtual address space, one or more threads, and some OS kernel state. • Threads can exist outside of processes too!

  43. Memory and the CPU 0 OS code CPU OS data Program A data Data R0 x Program B Rn Data x PC registers Does the CPU know about threads? main memory

  44. The Kernel • The kernel program resides in a well-known executable file. • The “machine” automatically loads the kernel into memory (boots) on power-on or reset. • The kernel is (mostly) a library of service procedures shared by all user programs, but thekernel is protected: • User code cannot access internal kernel data structures directly. • User code can invoke the kernel only at well-defined entry points • What are those? • (system calls).

  45. The Kernel (cont’d) • Kernel code is like user code, but the kernel is privileged: • Kernel has direct access to all hardware functions, and defines the machine entry points for interrupts and exceptions. • Q: like to keep the kernel small … why?

  46. A Protected Kernel Mode register bit indicates whether the CPU is running a user program or in the protected kernel. Some instructions or data accesses are only legal when the CPU is executing in kernel mode. 0 OS code CPU y OS data Program A data Data mode R0 x Program B Rn Data x PC registers 2n main memory Why can’t the OS do this alone?

  47. Threads • A thread is a schedulable stream of control. • defined by CPU register values (PC, SP) • suspend: save register values in memory • resume: restore registers from memory • Multiple threads can execute independently: • They can run in parallel on multiple CPUs... • - physical concurrency • …or arbitrarily interleaved on a single CPU. • - logical concurrency • Each thread must have its own stack.

  48. Architecture 101 • How does the OS interact with the hardware? 50K feet • I/O Structure • Storage Structure • Hardware Protection • OS has special code to communicate with controllers –what is it? • Much of the OS code is device drivers …

  49. Life is more complicated

  50. Driver Code is Fun! iface_desc = interface->cur_altsetting; for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; if (!dev->bulk_in_endpointAddr && (endpoint->bEndpointAddress & USB_DIR_IN) && ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK)) { buffer_size = endpoint->wMaxPacketSize; dev->bulk_in_size = buffer_size; dev->bulk_in_endpointAddr = endpoint->bEndpointAddress; dev->bulk_in_buffer = kmalloc(buffer_size, GFP_KERNEL); if (!dev->bulk_in_buffer) { err("Could not allocate bulk_in_buffer"); goto error;}} // LOTS MORE! THIS IS THE HIGH-LEVEL STUFF, NOT ASM

More Related