Today

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