the big picture
play

The Big Picture Thierry Sans Goals of this lecture Define what an - PowerPoint PPT Presentation

The Big Picture Thierry Sans Goals of this lecture Define what an Operating System is Explain how an OS works in a nutshell Bridge the gap between hardware (CSCB58) and systems programming (CSCB09) Give an overview of the course


  1. The Big Picture Thierry Sans

  2. Goals of this lecture • Define what an Operating System is • Explain how an OS works in a nutshell • Bridge the gap between hardware (CSCB58) and systems programming (CSCB09) • Give an overview of the course content and projects

  3. The big picture in 5 pieces The need for bootstrapping project 0 and system calls The need for concurrency project 1 The need for user spaces project 2 The need for virtual memory project 3 The need for a filesystem project 4

  4. 0x FF FF FF FF Simple Computer Architecture I/O Memory + CPU RAM Boot for a more accurate and detailed map of the x86 memory BIOS look at https://wiki.osdev.org/Memory_Map_(x86) 0x 00 00 00 00

  5. Each processor has its Instruction Set Architecture (ISA) Processor executes instructions stored in memory ➡ Each instruction is a bit string that the processor understands as an operation • arithmetic • read/write bit strings • bit logic • jumps ✓ ~2000 instructions on modern x86-64 processors

  6. 0x FF FF FF FF Running one program I/O stack stack pointer (esp) heap heap code (text) instruction pointer (eip) Boot

  7. The need for bootstrapping and system calls

  8. 0x FF FF FF FF Bootstrapping I/O Step 5: using the terminal, users can execute programs stack (e.g Bash terminal) ... and repeat heap Step 4: the kernel starts the user-interface program (e.g Bash terminal) whoami Terminal Step 3: the bootloader loads the OS kernel in RAM Kernel Step 2: the BIOS loads the bootloader from a device Bootloader (hard-drive, USB, network ...) based on the configuration Step 1: Power -on! The CPU starts executing code BIOS BIOS contained in the BIOS (basic input/output system) 0x 00 00 00 00

  9. The need for abstraction for user programs How to write a user program like the Bash shell that reads keyboard inputs from the user? ➡ Read input data from the I/O device directly? But which one? • The one connected to the PS2 port? • The one connected to the USB? • The one connected to the bluetooth? • The remote one connected to the network? ๏ User programs do not operate I/O devices directly ✓ The OS abstracts those functionalities and provide them as system calls

  10. System Calls user program ➡ Provide user programs with an API to use the Shell services of operating system kernel There are 5 categories of system calls system call • Process control read • File management • Device management • Information/maintenance (system configuration) memory • Communication (IPC) I/O • Protection ✓ There are 393 system calls on Linux 3.7 http://www.cheat-sheets.org/saved-copy/Linux_Syscall_quickref.pdf

  11. user program Shell In reality, many (many) level of c std lib abstraction and modularity scanf system lib scanf kernel system call read kernel module ➡ This is what makes developing OS interface very challenging (CSCB07) get device driver load memory I/O

  12. The need for concurrency

  13. Running multiple programs one after the other I/O Problem : the CPU is waiting for I/O (polling) stack cpu prog A prog B heap running heap idle prog B time prog A Problem: the programs must co-exists in memory (coming next with virtual memory)

  14. I/O with interrupts I/O Interrupt stack esp heap heap code (text) eip Boot

  15. Running multiple programs concurrently Problem : concurrent access to I/O devices must be synchronized I/O Problem : what if the program does not do any stack B IO and use the CPU for a long time cpu (a.k.a starvation problem) heap B prog B running stack A idle heap A prog B time prog A prog A Problem : the programs and their stacks must co- exists in memory (coming next with virtual memory)

  16. Using the clock I/O to trigger an interrupt Interrupt stack esp heap heap code (text) eip Boot

  17. Process States created waiting running blocked terminated

  18. With concurrency ✓ From the system perspective better CPU usage resulting in a faster execution overall (but not individually) ✓ From the user perspective programs are executed in parallel ➡ But it requires scheduling, synchronization and some protection mechanisms

  19. Achieving parallelism with I/O multi-core processors Interrupt stack esp heap core1 core2 core3 core4 heap code (text) eip Boot

  20. Other problems that we are going to address during the semester • Scheduling Decide which process to execute when severals are ready to be run • Synchronization Manage concurrent access to resources using semaphores, locks, monitors • Communication Exchange messages between processes using IPC (sockets & signals) • Threads Lightweight concurrency within a process

  21. The need for user spaces

  22. An old problem from older constraints stack B One computer and many users heap B prog B Problem : what prevents Alice's stack A from reading Bob's data? heap A • or start/stop any programs? prog A • or access any file on the filesystem • or use any I/O device? • or change the system configuration? • or reboot the machine?

  23. Definition of the user space principle 1 : user have full privileges stack B with their own user space heap B principle 2 : every access to another prog B user space must go through the kernel stack A via system calls (complete mediation) heap A prog A principle 3 : system calls can be user mode kernel mode allowed or denied based on the system security policy (access control) read

  24. Is multi-user paradigm obsolete? ➡ Most servers, personal computers, mobile and embedded systems have a single physical user ๏ But not all programs are reliable nor trustworthy ✓ It is still a good model to provide reliability and security

  25. The need for virtual memory

  26. The problem of managing the memory How to make programs and execution contexts co- stack B exists in memory? heap B ✓ Placing multiple execution contexts (stack and heap) prog B at random locations in memory is not a problem ... stack A ... well, as long as your have enough memory heap A ๏ However having programs placed at random prog A locations is problematic

  27. Let's look at some C code and its binary Since function addresses and others are hard-encoded in the binary, the program cannot be placed at random locations in memory

  28. 0x FF FF FF FF 0x FF FF FF FF stack B heap B prog A heap B stack B prog B physical memory 0x 00 00 00 00 heap A virtual memory stack A for program B prog B 0x FF FF FF FF 0x 00 00 00 00 stack A Virtual Memory heap A prog A The OS keeps track of the virtual memory 0x 00 00 00 00 mapping table for each process and translates virtual memory the addresses dynamically for program A

  29. Another problem What if we run out of memory because of too many concurrent programs? ✓ Swap memory move some data to the disk ➡ Managing memory becomes very complex but necessary

  30. 0x FF FF FF FF 0x FF FF FF FF Swap stack B prog A heap B stack B prog B physical memory 0x 00 00 00 00 virtual memory stack A for program B prog B 0x FF FF FF FF 0x 00 00 00 00 stack A heap A heap A prog A hard drive 0x 00 00 00 00 heap B virtual memory for program A

  31. The need for a file system

  32. Files and Directories versus Reality

  33. So, what is an operating system ?

  34. Operating System ➡ In a nutshell, an OS manages hardware and runs programs • creates and manages processes • manages access to the memory (including RAM and I/O) • manages files and directories of the filesystem on disk(s) • enforces protection mechanisms for reliability and security • enables inter-process communication

  35. For next week • Read the book • Read Pintos documentations (0-Introduction and A-Reference Guide) • Work on Project 0 (to be finalized in the next couple of days)

Recommend


More recommend