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