2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems So what is an OS? Opera.ng Systems History and Overview Por*ons of this material courtesy Profs. Wong and Stark 2-2 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems One view of an OS Another simple view of an OS App App App App OS Hardware 2-3 2-4 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems A less happy view of an OS So which one is right? • They all are 2-5 2-6 1
2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems An OS serves three masters Background (1) 1. Give users a desktop environment • CPUs have 2 modes: user and supervisor – Some*mes more, but whatevs 2. Give applica*ons a more usable abstrac*on of the hardware • Supervisor mode: 3. Give hardware manufacturers an abstrac*on of the – Issue commands to hardware devices applica*ons – Power off, Reboot, Suspend – Launch missiles, Do awesome stuff • User mode: – Run other code, hardware taXles if you try anything reserved for the supervisor 2-7 2-8 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems OS architecture OS architecture App App App App App App App App User Libraries Super- OS visor Kernel Hardware Hardware 2-9 2-10 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems Master #2: Applica*ons OS architecture • Applica*on Programming Interface (API) – Win32 (Windows) – POSIX (Unix/Linux) App App App App – Cocoa/Cocoa Touch (Mac OS/iOS) • Applica*on-facing func*ons provided by libraries User – Injected by the OS into each applica*on Libraries Super- visor Kernel Hardware 2-11 2-12 2
2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems OS architecture Famous libraries, anyone? • Windows: ntdll.dll, kernel32.dll, user32.dll, gdi32.dll • Linux/Unix: libc.so, ld.so, libpthread.so, libm.so Win32 App App App API Libraries Libraries Libraries User Super- visor Kernel Hardware 2-13 2-14 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems Caveat 1 System Call • Libraries include a lot of code for common func*ons • Special instruc*on to switch from user to supervisor mode – Why bother reimplemen*ng sqrt? • Transfers CPU control to the kernel • They also give high-level abstrac*ons of hardware – Files, printer, dancing Homer Simpson USB doll – One of a small-ish number of well-defined func*ons • How many system calls does Windows or Linux • How does this work? have? – Windows ~1200 – Linux ~350 2-15 2-16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems OS architecture Caveat 2 • Some libraries also call special apps provided by the OS, called a daemon (or service) Ok, here’s Open file – Communicate through kernel-provided API handle 4 “hw1.txt” • Example: Print spooler App App App – App sends pdf to spooler Libraries Libraries Libraries User – Spooler checks quotas, etc. Super- – Turns pdf into printer-specific format System Call Table (350—1200) visor – Sends reformaXed document to device via OS kernel Kernel Hardware 2-17 2-18 3
2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems OS architecture Master 3: Hardware • OS kernels are programmed at a higher low level of abstrac*on – Disk blocks vs. specific types of disks • For most types of hardware, the kernel has a “lowest App App Daemon common denominator” interface – E.g., Disks, video cards, network cards, keyboard Libraries Libraries Libraries User – Think Java abstract class Super- System Call Table (350—1200) – Some*mes called a hardware abstrac*on layer (HAL) visor • Each specific device (Nvidia GeForce 600) needs to Kernel implement the abstract class – Each implementa*on is called a device driver Hardware 2-19 2-20 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems OS architecture What about Master 1 • What is the desktop? • Really just a special daemon that interacts closely App App Daemon with keyboard, mouse, and display drivers Libraries Libraries Libraries User – Launches programs when you double click, etc. – Some program libraries call desktop daemon to render Super- System Call Table (350—1200) visor content, etc. Kernel HAL Driver Driver Driver Hardware 2-21 2-22 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems An OS serves three masters Mul*plexing Resources 1. Give users a desktop environment • Many applica*ons may need to share the hardware – Desktop, or window manager, or GUI • Different strategies based on the device: 2. Give applica*ons a more usable abstrac*on of the – Time sharing: CPUs, disk arm hardware • Each app gets the resource for a while and passes it on – Space sharing: RAM, disk space – Libraries (+ system calls and daemons) • Each app gets part of the resource all the *me 3. Give hardware manufacturers an abstrac*on of the – Exclusive use: mouse, keyboard, video card applica*ons • One app has exclusive use for an indefinite period Device Driver API (or HAL) – 2-23 4
2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems So what is Linux? So what is Ubuntu? Centos? • Really just an OS kernel • A distribu.on: bundles all of that stuff together – Including lots of device drivers – Pick versions that are tested to work together – Usually also includes a sonware update system • Conflated with environment consis*ng of: – Linux kernel – Gnu libc – X window manager daemon – CUPS printer manager – Etc. 2-25 2-26 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems OSX vs iOS? What is Unix? • Same basic kernel (a few different compile op*ons) • A very old OS (1970s), innova*ve, s*ll in use • Different window manager and libraries • Innova*ons: – Kernel wriXen in C (first one not in assembly) • Co-designed C language with Unix – Several nice API abstrac*ons • Fork, pipes, everything a file • Several implementa*ons: *BSDs, Solaris, etc. – Linux is a Unix-like kernel 2-27 2-28 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems What is POSIX? History of Opera*ng Systems • A standard for Unix compa*bility • Two ways to look at history: • Even Windows is POSIX compliant! – Evolu*on of the Theory – Evolu*on of the Machine/Hardware 2-29 5
2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems Evolu*on of OS Theory Evolu*on of OS Machine/Hardware 1. Centralized opera*ng system – Resource management and mul*programming, Virtuality 2. Network opera*ng system Resource sharing to achieve Interoperability – 3. Distributed opera*ng system – Singe computer view of a mul*ple computer system for Transparency 4. Coopera*ve autonomous system – Coopera*ve work with Autonomicity CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems 1940’s – First Computers 1940’s – First Computers • One user/programmer at a *me (serial • Vacuum Tubes and Plugboards – Program loaded manually using switches Single group of people designed, built, • – Debug using the console lights programmed, operated and maintained each machine • ENIAC • No Programming language, only absolute machine language (101010) – 1 st gen purpose machine • O/S? What is an O/S? • All programs basically did numerical – Calcula*ons for Army calcula*ons Pros: Cons: – Each panel had specific • Interac*ve – immediate • Lots of Idle *me func*on response on lights – Expensive computa*on • Programmers were women • Error-prone/tedious J • Each program needs all driver ENIAC (Electronic Number Integrator and Computer) code CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems 1950’s – Batch Processing Monitor’s Perspec*ve • Deck of cards to describe job • Monitor controls the sequence of • Jobs submiXed by mul*ple users are sequenced events automa*cally by a resident monitor • Resident Monitor is sonware always • Resident monitor was a basic O/S in memory – S/W controls sequence of events • Monitor reads in job and gives – Command processor control – Protec*on from bugs (eventually) • Job returns control to monitor – Device drivers 6
2/29/16 CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems 1950’s – Batch Processing Mul*programmed Batch Systems • CPU is onen idle – Even with automa*c job sequencing. – I/O devices are slow compared to processor IBM 7090 Pros: Cons: CPU kept busy, less idle *me • No longer interac*ve – longer • turnaround *me Monitor could provide I/O • services • Debugging more difficult • CPU s*ll idle for I/O-bound jobs • Buggy jobs could require operator interven*on CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems Uniprogramming Mul*programming • Processor must wait for I/O instruc*on to complete • When one job needs to wait for I/O, the processor before preceding can switch to the other job CSE 306: Opera.ng Systems CSE 306: Opera.ng Systems Mul*programming 1960’s – Mul*programming (*me-sharing) • CPU and I/O devices are mul*plexed (shared) between a number of jobs – While one job is wai*ng for I/O another can use the CPU – SPOOLing: Simultaneous Peripheral Opera*on OnLine • 1 st and simplest mul*programming system • Monitor (resembles O/S) – Starts job, spools opera*ons, I/O, switch jobs, protec*on between memory 7
Recommend
More recommend
