Operating Systems User OS Kernel & Device Drivers Interface Programs Instructor Brian Mitchell - Brian bmitchel@mcs.drexel.edu www.mcs.drexel.edu/~bmitchel TA - To Be Announced Course Information MCS720 Tuesday s 6-9 PM Online Information www.mcs.drexel.edu/~bmitchel/course/mcs720 Please check course web page several times per week. The web page will be my primary mechanism for communicating: Special and Emergency Information (posted by 12:00 noon on day of the class) Syllabus Assignments Exam Information Solutions to Problems Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 1 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 2 Course Objective To investigate classical internal algorithms and structures of operating systems Machine Architectures Concurrent Programming Textbook Applied Operating Systems Concepts, Avi Silberschatz, Peter Galvin, Greg Gagne Additional References Modern Operating Systems, Andrew Tanenbaum Distributed Operating Systems, Andrew Tanenbaum Selected research papers Homework s, Projects, Exams Programming Projects: This course will include a significant project that can be worked on individually or in teams. Specifications for the project are on the course web page. Research Presentation: This course will require you review research papers related to operating systems, as well as present a paper that you select to the class. Final: There will be a 90 minute final exam Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 3 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 4 1
Course Topics Project Processes & Threads Process Synchronization CPU Scheduling Memory Management Virtual Memory Deadlock File and I/O Systems Directory Services Security and Protection Operating System Case Studies Special Purpose Operating Systems Embedded JavaOS WebOS Learn about the internals of operating systems, operating system algorithms, and operating system and hardware integration. Goal: Construct a simulated: Hardware Operating System Assembler User Programs Operating System Hardware Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 5 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 6 Project Project Sample Programming Language Simple, pseudo-assembler based Instructions: Nop, alm, frm, cmp, jeq, jgt, jlt, jge, jle, clr, inc, dec, add, sub, mul, div, mov, and, or, not, xor, hlt, dis Processing the programs FIRST INSTRUCTION Get Instruction Sample Program start: alm R1,d500 ;allocate 500 bytes mov R2,#0 ;R2 will hold our offset looptop: mov (R1)+R2,R2 ;update memory location ;with value inc R2 ;increment R2 cmp R2,d500 ;compare R2 to 500 jlt looptop ;if R2<500 go to looptop halt ;stop execution Validate Instruction Fetch and resolveopcode arguments (if any) Execute Instruction Check and Handle Faults (if any) Log Instruction Results in the Hardware Trace NEXT INSTRUCTION Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 7 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 8 2
Project Project OS Memory Manager Linked Lists First, best, next, worst fit allocation algorithm Interface with the page table in hardware Handle program and page faults Provide interface to user programs who require memory Interface with hardware to manage the memory Simulated hardware General Purpose Registers R1 R2 R3 R4 R5 R6 R7 R8 Control Registers C T PF PC Physical Memory TLB* CACHE* PAGE TABLE SWAP Space Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 9 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 10 Project Information Getting Started Sample code and ant (www.apache.org) script is provided in the project page Grading The following distribution will be used to determine your final grade in this course: 20%: Phase 1 Project Deliverable 10%: Phase 2 Project Deliverable 30%: Phase 3 Project Deliverable 20%: Research Paper Presentation 20%: Final Exam Policies Policies governing the project are described on the project web page. Makeup exams will take the form of an oral exam or an alternative test (in-class or take-home). Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 11 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 12 3
Computer hardware requires software to perform useful operations Types of software Systems Programs: manage the operation of the computer itself Application Programs: solve user problems The Operating System (OS) is the most fundamental of all systems programs OS controls ALL of the computers resources OS provides VALUABLE services to user programs OS COORDINATES the execution of user programs OS PROVIDES resources to user programs Computer Systems Structure Modern computer systems consist of: One or more processors Main memory Clocks (Synchronization, coordination) Terminals Disks Network Interfaces Input/Output Devices Systems Architectures SISD, SIMD, MIMD, MISD (we will look at these later) Processor Organization Single Processor Multiprocessor Symmetric Multiprocessor Distributed Clusters Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 13 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 14 Rationale for OS OS Architecture Directly interfacing user programs with hardware is COMPLEX Building programs for specific computer architectures is not portable If every program included code to interface with the computer hardware Redundancy Inconsistent quality Inefficient use of resources DESIRE => Shield programmers from the complexity of the hardware OS is a layer that sits on top of the hardware OS provides an interface or virtual machine that is easy to understand and program Most Operating Systems use a layered architecture Banking System Compilers Airline Reservation Editors Operating System Machine Language Microprogramming Physical Devices Word Processor Command Interpreter USER SYSTEM HARDWARE Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 15 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 16 4
OS Architecture (con t) OS Architecture (con t) Physical Devices Computer hardware - CPU, memory, I/O devices, network interfaces Microprogramming ROM-based programs Controls CISC processors Machine Language Instructions supported by the hardware Binary encoded Processors typically support 50-300 instructions CISC vs RISC Use registers as the basis for performing most operations Running programs Device interfaces Operating Systems Hide the complexity of software Read 200 bytes from file A versus managing the motor and arms of the disk drive Provide an interface for the programmer Usually documented as a set of API s ex: Win32 on Windows98 & WindowsNT Win32 contains about 6,000 API s OpenFile(), CreateProcess(),... Systems software usually sits on top of the kernel of the OS Command Interpreter, Security Manager, Utilities (e.g., awk, grep on Unix) Most processors support multiple execution modes Minimally Kernel/Supervisor and User modes Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 17 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 18 OS Architecture (con t) OS Architecture - Summary Operating system runs in Kernel mode and user programs run in User mode Kernel Mode Full access to machine instruction set Direct access to hardware, memory, and input/output devices OS and device drivers must run in Kernel mode User Mode Access to a limited set of machine instructions No direct access to hardware, memory and input/output devices Device access is coordinated by OS Typically user mode instructions consist of computational instructions MS DOS only supported Kernel mode Operating System acts as an extended machine from a user program perspective Reduce complexity Increase system integrity Reduce redundancy Operating System acts as a resource manager Hardware provides many resources to user programs Demand for resources may exceed resource capacity OS must optimally manage allocation of the resources Ex: Memory, Processor/CPU time Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 19 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 20 5
Example: Web Browser History of Operating Systems Socket API TCP/IP Frames Memory-Mapped Electrical Signals WEB Browser http://www.mcs.drexel.edu Operating System Device Driver Network Interface Card (NIC) Network User Mode Switch to Kernel Mode Kernel Mode First Generation (1945-1955) Hardware was tube-based Programs were hardwired on plugboards Hardware could run one program at a time Applications: Numerical Calculations Second Generation (1955-1965) Transistor-based Assembler - improvement over machine language High Level Language - FORTRAN Batch oriented Jobs were created on card or tape Jobs were serially executed Scientific / Engineering applications Early operating systems introduced Capabilities limited to controlling the serial execution of batch jobs Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 21 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 22 History of Operating Systems History of Operating Systems Third Generation (1965-1980) IC circuits (LSI, VLSI chips) Business applications supported in addition to scientific and engineering applications Business Applications: IO-based Engineering/Scientific Applications : CPUbased OS supported several new capabilities Multiprogramming Load multiple jobs into memory When one job was waiting for I/O the OS ran another job Job spooling - queue of ready to run jobs reduced operator intervention Timesharing Support for multiple, concurrent users OS timeslices user sessions OS takes responsibility for maximizing CPU and device utilization Fourth Generation (1980 - ) Workstations and PC s Computer networks become commonplace CPU s with millions of transistors offer high computational power Desire: User friendly software Result: Complex operating systems OS designed to scale and integrate well with new computer architectures Real time / Embedded SMP CISC, RISC Parallel Network OS address new concerns Network transparency Security Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 23 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 24 6
History of Operating Systems Fifth Generation (2000? -???? ) OS designed to support massively parallel computer architectures Thousands of CPU s MPP architectures may consist of thousands of independent computers connected by high -speed networks ex: BISDN at 155Mbits/sec MPP architectures may consist of processor boards plugged into custom design backplanes One or multiple copies of the OS? Issues Cache coherence Management and coordination of distributed resources Bandwidth limitations Keeping consistent time Special Operating System Types Distributed Systems Goal is to distribute the computation across several physical processors Can use either standard networks, or proprietary inter-connection technologies Advantages: Scalability at low cost Reliability Disadvantages: Programming is complex Overhead may be large Real time systems Typically used to control a device Well defined time constraints must be respected General purpose operating systems do not often handle the requirements of a realtime system Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 25 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 26 Operating System Components Operating System Components Process Management A process is a program in execution OS manages the creation and deletion of processes Main-Memory Management OS keeps track of memory in use and free memory, who is using the memory, allocation and freeing of memory. Secondary-Storage Management OS uses secondary storage to extend physical memory Secondary Storage typically resides on disk I/O System Management OS uses the I/O system for management of devices (device drivers) Caching Example: File System File Management OS Manages the creation and deletion of files, and directories OS also manages file system permissions Who owns the file, who can modify the file Protection System Distinguish authorized versus nonauthorized usage of OS resources Networking Enables OS users to utilize network resources Remote disks, Internet, shared printers, file servers, email, Command-Interpreter System, Graphical User Interfaces Provides the user with an interface for using the operating system facilities Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 27 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 28 7
Operating System Interfaces Virtual Machines Operating Systems typically provide two interfaces: User interfaces: Command Line Interpreter, or graphical user interface Program interfaces: OS provide interfaces via application programming interfaces to programs. Sometimes called system calls System Calls Operating system designers typically package system calls as C language function calls Example: Win32 on Windows 95/98/NT Most operating systems also provide additional classes for better integration with object oriented languages such as C++ Example: MFC on Windows 95/98/NT A virtual machine takes the layered approach to its logical conclusion. It treats hardware and the operating system kernel as though they were all hardware. A virtual machine provides an interface identical to the underlying bare hardware. The operating system creates the illusion of multiple processes, each executing on its own processor with its own (virtual) memory. Some operating systems (e.g., VM by IBM), work by running all processes in a virtual machine VM concepts are most widely applied in interpretive languages (e.g., Java) Interface to the machine is facilitated by the virtual machine Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 29 Brian Mitchell (bmitchel@mcs.drexel.edu) - Operating Systems 30 8