Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "COSC 3407: Operating Systems Lecture 1: Introduction Kalpdrum Passi."— Presentation transcript:

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

2 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?

3 Course overview u Website: http://www.cs.laurentian.ca/kpassi/cosc3407.html u Instructor: » Kalpdrum Passi (kpassi@cs.laurentian.ca)kpassi@cs.laurentian.ca u Key dates: – Lectures: MonWed 10:00-11:30 in FA 358 – Midterm: Monday, February 24, 2014

4 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.

5 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!

6 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

7 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

8 Abstract View of System Components

9 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.)

10 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.

11 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.

12 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 Email 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?

13 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

14 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

15 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.

16 MS-DOS Layer Structure

17 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?

18 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

19 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

20 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.

21 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.

22 Address translation (cont.)

23 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.

24 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.

25 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.

26 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?

27 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

28 UNIX System Structure User Mode Kernel Mode Hardware Applications Standard Libs

29 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

30 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?

31 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.


Download ppt "COSC 3407: Operating Systems Lecture 1: Introduction Kalpdrum Passi."

Similar presentations


Ads by Google