SCSC 511 Operating Systems Chapter 2 Operating Systems Structures - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

SCSC 511 Operating Systems Chapter 2 Operating Systems Structures

Description:

Settles conflicting requests for resources. Prevent errors and improper use of the computer ... 'ENIAC designed by Drs. Eckert and Mauchly was a monstrosity. ... – PowerPoint PPT presentation

Number of Views:108
Avg rating:3.0/5.0
Slides: 35
Provided by: johnk208
Category:

less

Transcript and Presenter's Notes

Title: SCSC 511 Operating Systems Chapter 2 Operating Systems Structures


1
SCSC 511 Operating Systems Chapter 2
Operating Systems Structures
Dr. Frank Li Fall 2008
2
Review What does an Operating System do?
  • Coordinator
  • Manages all resources
  • Settles conflicting requests for resources
  • Prevent errors and improper use of the computer
  • Facilitator
  • Provides facilities that everyone needs
  • Standard Libraries, Windowing systems
  • Make application programming easier, faster, less
    error-prone
  • Silerschatz and Gavin An OS is a program that
    manages the computer hardware.

3
Review Virtual Machine Abstraction
Application Operating System Hardware
Virtual Machine Interface
Physical Machine Interface
  • Software Engineering Problem
  • Turn hardware/software quirks ? what
    programmers want/need
  • Optimize for convenience, utilization, security,
    reliability, etc
  • For Any OS area (e.g. file systems, virtual
    memory, networking, scheduling)
  • Whats the hardware interface? (physical reality)
  • Whats the application interface? (nicer
    abstraction)

4
Goals for Today
  • History of Operating Systems
  • a history of resource-driven choices
  • Operating System Services
  • System Calls
  • Operating Systems Structures

5
Dawn of timeENIAC (19451955)
  • ENIAC designed by Drs. Eckert and Mauchly was a
    monstrosity.
  • When it was finished, the ENIAC filled an entire
    room, weighed thirty tons, and consumed two
    hundred kilowatts of power.
  • http//ei.cs.vt.edu/history/ENIAC.Richey.HTML

6
History Phase 1 (19481970)Hardware Expensive,
Humans Cheap
  • When computers cost millions of s, optimize for
    more efficient use of the hardware!
  • User at console one user at a time
  • Batch computing load program, run, print
  • Optimize to better use hardware
  • Do NOT support user interaction Why?
  • Ans When user thinking at console, computer
    idle ? BAD!
  • Feed computer batches and make users wait
  • At that time, OS usually has no protection
  • What if a batch program has bug?

7
History Phase 1½ (late 60s - early 70s)
  • Data channels, Interrupts overlap I/O and
    compute
  • DMA Direct Memory Access for I/O devices
  • I/O can be completed asynchronously
  • Multiprogramming several programs run
    simultaneously
  • Small jobs not delayed by large jobs
  • Overlap between I/O and CPU computing ? not batch
    computing any more
  • Need memory protection among programs and OS
  • Complexity gets out of hand
  • E.g., Multics was announced in 1963, ran in 1969
  • 1777 people who contributed to Multics.
    Probably 30-40 core developers.

8
Example A Multics System
  • A Multics System at MIT (1976)
  • We usually ran the machine with doors open so
    the operators could see the AQ register display,
    which gave you an idea of the machine load, and
    for convenient access to the EXECUTE button,
    which the operator would push to enter BOS if the
    machine crashed.
  • http//www.multicians.org/multics-stories.html

9
History Phase 2 (1970 1985)Hardware Cheaper,
Humans Expensive
  • Computers available for tens of thousands of
    dollars instead of millions
  • OS Technology maturing/stabilizing. Interactive
    timesharing
  • Use cheap terminals (1000) to let multiple
    users interact with the system at the same time
  • Sacrifice CPU time to get better response time
  • Users do debugging, editing, and email online

10
History Phase 3 (1981 )Hardware Very Cheap,
Humans Very Expensive
  • Computer costs 1K, Programmer costs 100K/year
  • If you can make someone 1 more efficient by
    giving them a computer, its worth it!
  • Personal computing
  • Computers cheap, so give everyone one/multiple
    PCs
  • Initially PCs have limited hardware resources
  • One application at a time (MSDOS)
  • Eventually PCs become powerful
  • OS regains all the complexity of a big OS
  • multiprogramming, memory protection, etc
    (Windows, OS/2, MAC, Linux)

11
History Phase 3 (cont)Graphical User Interfaces
  • Xerox Star 1981
  • Originally a researchproject (Alto)
  • First mice, windows
  • Apple Lisa/Machintosh 1984
  • Look and Feel suit 1988
  • Microsoft Windows

12
History Phase 4 (1989) Distributed Systems
  • Computer Networking (Local area networking)
  • Different machines share resources
  • Printers, File Servers, Web Servers
  • Client Server computing model
  • Severs provide Services
  • Computing
  • File Storage

13
History Phase 5 (1995) Mobile Systems
  • Ubiquitous Mobile Devices
  • Laptops, PDAs, phones
  • Small, portable, and inexpensive
  • Recently twice as many smart phones as PDAs
  • Many computers per person
  • With limited capabilities (memory, CPU, power,
    etc)
  • Wireless/Wide Area Networking
  • Leveraging the infrastructure
  • Huge distributed pool of resources extend devices
  • Peer-to-peer computing model
  • Many devices with equal responsibilities work
    together
  • Components of Operating System spread across
    globe

14
History of OS Summary
  • Change is continuous and OSs should adapt
  • Not look how stupid batch processing was
  • But Made sense at the time
  • Situation today
  • Small OS 100K lines
  • Large OS 10M lines
  • 100-1000 people-years
  • Complexity still reigns

15
Goals for Today
  • History of Operating Systems
  • Operating System Services
  • System Calls
  • Operating Systems Structures

16
Operating System Services (1)
  • User interface (UI)
  • Command-Line (CLI)
  • Graphics User Interface (GUI)
  • Batch
  • Program execution
  • The system must be able to load a program into
    memory and to run that program, end execution,
    either normally or abnormally
  • I/O operations
  • A running program may require I/O, which may
    involve a file or an I/O device.
  • File-system manipulation
  • programs need to read and write files and
    directories, create and delete them, search them,
    list file Information, permission management.

17
Operating System Services (2)
  • Communications
  • Processes may exchange information, on the same
    computer or between computers over a network
  • Communications may be via shared memory or
    through message passing (packets moved by the OS)
  • Error detection
  • OS needs to be constantly aware of possible
    errors
  • For each type of error, OS should take the
    appropriate action to ensure correct and
    consistent computing

18
Operating System Services (3)
  • Resource allocation
  • When multiple users or multiple jobs running
    concurrently, resources must be allocated to each
    of them
  • Accounting
  • To keep track of which users use how much and
    what kinds of computer resources
  • Protection and security
  • The owners of information stored in a multiuser
    or networked computer system may want to control
    use of that information
  • concurrent processes should not interfere with
    each other

19
Goals for Today
  • History of Operating Systems
  • Operating System Services
  • System Calls
  • Operating Systems Structures

20
System Calls
  • System calls provide an interface to the services
    made available by the OS
  • Typically written in a high-level language (C or
    C)
  • Accessed by programs via a high-level Application
    Program Interface (API) rather than direct system
    call use
  • Three most common APIs
  • Win32 API for Windows
  • POSIX API for POSIX-based systems (including
    virtually all versions of UNIX, Linux, and Mac OS
    X),
  • Java API for the Java virtual machine (JVM)

21
Example of Standard API
  • ReadFile() function in the Win32 APIa function
    for reading from a file

22
API vs. System Calls
  • Q Why use APIs rather than system calls?
  • Answer
  • Convenience system calls are more difficult to
    work with than the API
  • Most programming languages provide a system call
    interface. The application programmers need to
    know nothing about how the system call is
    implemented or what it does during execution.
  • (figure 2.3)
  • Program portability programs using APIcan be
    compiled and run on any system that supports the
    same API

23
System Call Interface
24
Passing Parameters to OS
  • Three methods for Passing the parameters
  • Passing the parameters in registers
  • simple
  • However, therere limited number of registers in
    CPU
  • Passing the parameters as a table
  • Implemented in Linux, Solaris
  • The parameters are pushed into a stack by a
    application program, and popped off the stack by
    OS

25
Types of System Calls
  • Types of system calls
  • Process control
  • File management
  • Device management
  • Information maintenance
  • Communications
  • (Sections 2.4, 2.5, and 2.8 are not required)

26
Goals for Today
  • History of Operating Systems
  • Operating System Services
  • System Calls
  • Operating Systems Structures

27
Operating Systems Structures
  • Simple
  • Only one or two levels of code
  • Layered
  • Lower levels independent of upper levels
  • Microkernel
  • OS built from many user-level processes
  • Modular
  • Core kernel with Dynamically loadable modules

28
Simple Structure
  • MS-DOS
  • written to provide the most functionality in the
    least space
  • Not divided into modules
  • Interfaces and levels of functionality not well
    separated

There is only one operation mode in Intel 8088
CPU, on which MS-DOS runs. ? no hardware
protection. Thus, a buggy application program
easily crashes the whole system.
29
Layered Structure
  • Operating system is divided many layers. Each
    built on top of lower layers
  • Bottom layer (layer 0) is hardware
  • Highest layer (layer N) is the user interface
  • Each layer uses functions and services of only
    lower-level layers
  • Advantage modularity ? Easier debugging/Maintenan
    ce
  • Difficulties
  • Not easy to define various layers
  • Layered implementation tend to be less effective

30
Layered Operating System
31
UNIX
  • Original UNIX operating system consists of two
    separable parts
  • Systems programs (e.g., ls)
  • The kernel
  • Consists of everything below the system-call
    interface and above the physical hardware
  • Provides the file system, CPU scheduling, memory
    management, and other operating-system functions

32
Microkernel Structure
  • Moves as much from the kernel into user space
  • Small core OS running at kernel level
  • OS Services built from many independent
    user-level processes
  • Communication between modules with message
    passing
  • E.g., Tru64, QNX
  • Benefits
  • Easier to extend a microkernel
  • Easier to port OS to new architectures
  • More reliable (less code is running in kernel
    mode)
  • Fault Isolation (parts of kernel protected from
    other parts)
  • More secure
  • Detriments
  • Performance overhead severe for naïve
    implementation

33
Modules-based Structure
  • The best current methodology on OS design is
    modular kernel
  • Uses object-oriented approach
  • Each core component is separate
  • Each talks to the others over known interfaces
  • Each is loadable as needed within the kernel
  • Overall, similar to layers but with more flexible
  • E.g., Linux, Solaris, Mac OS X

34
In Conclusion
  • Rapid Change in Hardware Leads to changing OS
  • Batch ? Multiprogramming ? Timeshare ? Graphical
    UI ? Ubiquitous Devices
  • Standard Components and Services
  • Process Control
  • Main Memory
  • I/O
  • File System
  • UI
  • OS structures Simple, Layered, Microkernel,
    Modular
  • Complexity is always a big concern in OS design
Write a Comment
User Comments (0)
About PowerShow.com