COSC 3407: Operating Systems Lecture 1: Introduction Kalpdrum Passi.

Slides:



Advertisements
Similar presentations
Introduction CSCI 444/544 Operating Systems Fall 2008.
Advertisements

Introduction to Operating Systems CS-2301 B-term Introduction to Operating Systems CS-2301, System Programming for Non-majors (Slides include materials.
CMPT 300: Operating Systems I Dr. Mohamed Hefeeda
Architectural Support for OS March 29, 2000 Instructor: Gary Kimura Slides courtesy of Hank Levy.
1 School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Dr. Mohamed Hefeeda.
OS Fall ’ 02 Introduction Operating Systems Fall 2002.
W4118 Operating Systems OS Overview Junfeng Yang.
Operating System Structure. Announcements Make sure you are registered for CS 415 First CS 415 project is up –Initial design documents due next Friday,
OS Spring’03 Introduction Operating Systems Spring 2003.
1 Last Class: Introduction Operating system = interface between user & architecture Importance of OS OS history: Change is only constant User-level Applications.
1.1 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Instructor:
OS Spring’04 Introduction Operating Systems Spring 2004.
Copyright Arshi Khan1 System Programming Instructor Arshi Khan.
Basics of Operating Systems March 4, 2001 Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard.
CSE 451: Operating Systems Autumn 2013 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
Computer Organization
CSC139 Operating Systems Lecture 1 What is an Operating System? Adapted from Prof. John Kubiatowicz's lecture notes for CS162
Protection and the Kernel: Mode, Space, and Context.
1 COMPSCI 110 Operating Systems Who - Introductions How - Policies and Administrative Details Why - Objectives and Expectations What - Our Topic: Operating.
Introduction and Overview Questions answered in this lecture: What is an operating system? How have operating systems evolved? Why study operating systems?
Four Components of a Computer System. Computer System Components Users (people, machines, other computers) Applications programs – define the ways in.
Chapter 6 Operating System Support. This chapter describes how middleware is supported by the operating system facilities at the nodes of a distributed.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 1 Introduction Read:
WEEK 1 COURSE INTRODUCTION INTRODUCTION TO OPERATING SYSTEMS OPERATING SYSTEM STRUCTURES Operating Systems CS3013 / CS502.
1 Introduction to Operating Systems 9/16/2008 Lecture #1.
Architecture Support for OS CSCI 444/544 Operating Systems Fall 2008.
Introduction to Operating Systems Chapter 1. cs431 -cotter2 Lecture Objectives Understand the relationship between computing hardware, operating system,
1 COMPSCI 110 Operating Systems Who - Introductions How - Policies and Administrative Details Why - Objectives and Expectations What - Our Topic: Operating.
OPERATING SYSTEMS Goals of the course Definitions of operating systems Operating system goals What is not an operating system Computer architecture O/S.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 2: Operating-System Structures.
Operating Systems Lecture 7 OS Potpourri Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard. Zhiqing Liu School of Software.
Background: Operating Systems Brad Karp UCL Computer Science CS GZ03 / M th November, 2008.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
Chapter 1: Introduction and History  Where does the operating system fit in a computing system?  What does the operating system achieve?  What are the.
Processes Introduction to Operating Systems: Module 3.
CS 346 – Chapter 2 OS services –OS user interface –System calls –System programs How to make an OS –Implementation –Structure –Virtual machines Commitment.
1 CSE451 Architectural Supports for Operating Systems Autumn 2002 Gary Kimura Lecture #2 October 2, 2002.
Lecture Topics: 10/29 Architectural support for operating systems –timers –kernel mode –system calls –protected instructions.
Introduction to Operating Systems and Concurrency.
A. Frank - P. Weisberg Operating Systems Structure of Operating Systems.
Lecture 26 Virtual Machine Monitors. Virtual Machines Goal: run an guest OS over an host OS Who has done this? Why might it be useful? Examples: Vmware,
Introduction Why are virtual machines interesting?
Lecture 4 Page 1 CS 111 Online Modularity and Virtualization CS 111 On-Line MS Program Operating Systems Peter Reiher.
Protection of Processes Security and privacy of data is challenging currently. Protecting information – Not limited to hardware. – Depends on innovation.
Operating Systems CMPSC 473 Introduction and Overview August 24, Lecture 1 Instructor: Bhuvan Urgaonkar.
CSCI/CMPE 4334 Operating Systems Review: Exam 1 1.
1 Chapter 2: Operating-System Structures Services Interface provided to users & programmers –System calls (programmer access) –User level access to system.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edit9on Chapter 1: Introduction.
SCSC 511 Operating Systems Chapter 1 Introduction Dr. Frank Li Fall 2016.
Introduction to Operating Systems Concepts
Computer System Structures
Chapter 1: Introduction
Memory Protection: Kernel and User Address Spaces
CS490 Windows Internals Quiz 2 09/27/2013.
CSCI 511 Operating Systems Chapter 1 Introduction
Introduction and History
Introduction and History
Memory Protection: Kernel and User Address Spaces
Memory Protection: Kernel and User Address Spaces
Introduction and History
Lecture Topics: 11/1 General Operating System Concepts Processes
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
Introduction and History
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
CSE 451: Operating Systems Winter 2007 Module 2 Architectural Support for Operating Systems Brian Bershad 562 Allen Center 1.
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
Outline Operating System Organization Operating System Examples
System calls….. C-program->POSIX call
Introduction and History
Lecture Topics: 11/1 Hand back midterms
Presentation transcript:

COSC 3407: Operating Systems Lecture 1: Introduction Kalpdrum Passi

Today u Course overview u What is an operating system --- and what isn’t it? u Principles of operating system design u Why study operating systems?

Course overview u Website: u Instructor: » Kalpdrum Passi u Key dates: – Lectures: MonWed 10:00-11:30 in FA 358 – Midterm: Monday, February 24, 2014

Course Overview (Continued) u Material: – Lecture notes – On website. – Textbook – Silberschatz, Galvin, and Gagne, Operating System Concepts (Ninth Edition) u Prerequisites: – Data Structures – (COSC 2007) – Machine Structures – (COSC 2406) u Grading Policy – Project: 30% – Midterm Exam30% – Quiz’s/Assignments10% – Final Exam: 30% Give me a sign you learned the material.

Word of warning u I have a firm belief in you learn by doing. – Learn OS concepts by coding them! u Key Course Features – Most of the work comes from intense coding. – If the first piece of your project doesn’t work, the rest won’t work either. – This project is used at many other Universities, so it’s well known that it’s “doable.” – You will learn a lot! You will have to work hard!

Project u Use Nachos instructional system – Includes code for a simple but complete operating system and a machine simulator used to run “real” programs – Your task is to extend various components of Nachos u Goals – Learn how to read someone else’s code – Learn the internals of an operating system – Improve programming skills u Structure – Teams of 4 – start looking for partners – 2 parts: synchronization & threads, and multiprogramming

What is an operating system? u Definition: An operating system implements a virtual machine that is (hopefully) easier and safer to program and use than the raw hardware. application (user) Operating system hardware Virtual Machine Interface Physical Machine Interface

Abstract View of System Components

Operating System Definitions u In some sense, OS is just a software engineering problem: how do you convert what the hardware gives you into something that the application programmers want? u For any OS area (file systems, virtual memory, networking, CPU scheduling), you begin by asking two questions: – What’s the hardware interface? (the physical reality) – What’s the application interface? (the nicer abstraction) u Of course, should also ask why the interfaces look the way they do, and whether it might be better to push more responsibilities into applications or into hardware, or vice versa. (examples, RISC architectures, VBasic libraries, etc.)

Virtual Machines u Virtual machine model provides software emulation of an abstract machine u Also used to allow programs for one hardware & OS platform to run on another one (e.g., Windows programs on a Macintosh), perhaps even running several VMs concurrently. u Useful for OS research and development (much easier to debug) u Protection and portability (e.g., Java VM) u The project in this course is to build some of the portable components of an OS on top of Nachos, which provides a simulation environment. u That is, it simulates the hardware and machine-dependent layer (interrupts, I/O, etc.) and the execution of user programs running on top of it. u Note that Nachos runs on many different hardware/OS platforms.

Operating systems have two general functions 1. Coordinator & traffic cop: allow multiple applications/users to work together in efficient and fair ways (examples: concurrency, memory protection, file systems, networking). – This is Resource Allocation and Control. – Goals are fair management of shared resources, protection, and efficiency. 2. Standard services: provide standard facilities that everyone needs (examples: standard libraries, windowing systems). 1.View OS as a facilitator. 2.Goal is to make application programming easier, faster, and less error-prone.

So, what is in an OS and what isn’t? u Of course, there is no universal agreement on this but: u Most likely: – Memory management – i/o management – CPU scheduling – communications? (Does belong in OS?) – multitasking/multiprogramming u What about?: – File System – Multimedia support – User Interface (window manager) – Internet Browser?. u Bonus question: is this just of interest to academics? If not then why might it be important?

Operating System Definition (Cont.) u No universally accepted definition u “Everything a vendor ships when you order an operating system” is good approximation – But varies wildly u “The one program running at all times on the computer” is the kernel. – Everything else is either a system program (ships with the operating system) or an application program

What if you didn’t have an operating system? u source code -> compiler -> object code -> hardware u How do you get object code onto the hardware? u How do you print out the answer? u Before OS’s, used to have to toggle in program in binary, and then read out answers from LED’s! Altair 8080

Simple OS: What if only one application at a time? u Examples: – very early computers, – early PC’s, – embedded controllers (elevators, cars, Nintendos,...), PDAs, intelligent light switches,… u Then OS is just a library of standard services. – Examples: standard device drivers, interrupt handlers, math libraries, etc.

MS-DOS Layer Structure

More complex OS: what if you want to share the machine among multiple applications? u Full Coordination and Protection – Manage interactions between different applications and different users, – Multiplex and protect Hardware Resources » CPU, physical memory, I/O devices like disks and printers, interrupts, etc. u Facilitator – Still provide libraries of standard services. u Would this complexity make sense if there were only one application that you cared about?

Example of OS coordination: protection u Problem: How do different applications run on the same machine at the same time, without stomping on each other? u Goals of protection: – Keep user programs from crashing OS – Keep user programs from crashing each other u (Some of the required) Mechanisms: – Address Translation – Dual Mode Operation u Simple Policy: – Programs are not allowed to read/write memory of other Programs or of Operating System

Hardware support for protection u Hardware provides two things to help isolate a program’s effects to within just that program: – Address translation – Dual mode operation

Address translation u Address space: literally, all the memory addresses a program can touch. – All the state that a program can affect or be affected by. u Achieve protection by restricting what a program can touch! u Hardware translates every memory reference from virtual addresses to physical addresses; software sets up and manages the mapping in the translation box.

Address translation (cont.) u Two views of memory: – View from the CPU – what program sees, virtual memory – View from memory – physical memory u Translation box (also called a memory management unit) converts between the two views.

Address translation (cont.)

u Translation helps implement protection because there is no way for a program to even talk about other program’s addresses; no way for it to touch operating system code or data. u Translation also helps with the issue of how to stuff multiple programs into memory. u Translation is implemented using some form of table lookup (we’ll discuss various options for implementing the translation box later). u Separate table for each user address space.

Dual mode operation u Can an application modify its own translation tables? – If it could, then it could get access to all of physical memory. – Has to be restricted somehow. u Dual-mode operation – When in the OS, can do anything (called “kernel mode”, “supervisor mode”, or “protected mode”). – When in a user program, restricted to only touching that program’s memory (user-mode). u Implemented by setting a hardware-provided bit. u Restricted operations can only be performed when the “kernel- mode” bit is set. u Only the operating system itself can set and clear this bit.

Dual mode operation u HW requires CPU to be in kernel-mode to modify address translation tables. u Isolate each address space so its behavior can’t do any harm, except to itself. u Remember: don’t need boundary between kernel and application if system is dedicated to a single application.

Dual mode operation u So how do user programs do something privileged? – e.g., how can you write to a disk if you can’t do I/O instructions? u User programs must call an OS procedure – OS defines a sequence of system calls – how does the user-mode to kernel-mode transition happen?

Dual mode operation u There must be a system call instruction, which: – causes an exception (throws a software interrupt), which vectors to a kernel handler – passes a parameter indicating which system call to invoke – saves caller’s state (regs, mode bit) so they can be restored – OS must verify caller’s parameters (e.g. pointers) – must be a way to return to user mode once done

UNIX System Structure User Mode Kernel Mode Hardware Applications Standard Libs

Operating Systems Principles u Throughout the course, you’ll see four common themes recurring over and over: u OS as illusionist – make hardware limitations go away. OS provides illusion of dedicated machine with infinite memory and infinite processors. u OS as government – protect users from each other and allocate resources efficiently and fairly. u OS as complex system – keeping things simple is key to getting it to work; but there is a constant tension between this and the desire to add more functionality and performance. u OS as history teacher – learn from past to predict the future in order to improve performance. u Meta principles – OS design trade-offs change

Why study operating systems? u You need to understand enough to make informed decisions about things like: – Buying and using a personal computer: » Why do different PCs with the same CPU perform differently? » How do I choose between an AMD CPU and an Intel Itanium, Celeron, or Pentium 4 CPU? » Should I get Windows 2000? Windows XP? Linux? What’s the difference? » Should I upgrade my hardware? Should I upgrade my OS? » What’s going on with my PC, especially when I have to install something? » Should I use disk compression? Is there a cost to using it? – Business (and personal) decisions about thin-clients vs. PCs: » What are the issues involved? » What kinds of choices are being offered? – Business decisions in general: how important are various capabilities (such as fault tolerance) and what should they cost? – Security and viruses: what exposures do I have to worry about? – Why is the Web so slow sometimes and is there anything I can do about it?

Why study operating systems? u If you’re going to be a software engineer then you’ll need to understand various things about the environment offered by the OS you’re running on: – What abstractions does the OS provide? E.g., the OS may (or may not) provide illusions such as infinite CPU’s, infinite memory, single worldwide computing, etc. – What system design trade-offs have been made? » E.g., what functionality has been put in hardware? » What trade-offs have been made between simplicity and performance, putting functionality in hardware vs. software, etc? u Capstone: combines things from many other areas of computer science – languages, hardware, data structures, and algorithms; – In general, systems smarts, complex software development (in groups), and intuition for general systems tradeoffs.