Download Chapter 2: OS Structures

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Library (computing) wikipedia , lookup

Berkeley Software Distribution wikipedia , lookup

Security-focused operating system wikipedia , lookup

Acorn MOS wikipedia , lookup

Plan 9 from Bell Labs wikipedia , lookup

Copland (operating system) wikipedia , lookup

RSTS/E wikipedia , lookup

Burroughs MCP wikipedia , lookup

VS/9 wikipedia , lookup

Distributed operating system wikipedia , lookup

CP/M wikipedia , lookup

Unix security wikipedia , lookup

Process management (computing) wikipedia , lookup

DNIX wikipedia , lookup

Kernel (operating system) wikipedia , lookup

Paging wikipedia , lookup

Spring (operating system) wikipedia , lookup

Transcript
COSC 4740
Chapter 2
Operating System Structures
O/S Components
•
•
•
•
•
•
•
Process management
I/O management
Main Memory management
File & Storage Management
Networking/Communications
Protection and Error Detection
User interface
– Varies between Command-Line (CLI), Graphics User
Interface (GUI), Batch Command Interpreter
A View of Operating System
Services
Process Management
• Process (or job): A program or a fraction of a
program that is loaded in main memory and
executing.
– We do not need the entire program code at once.
To process an instruction, CPU fetches and
executes one instruction of a process after
another in the main memory.
Tasks of Process Management
o Create, load, execute, suspend, resume, and
terminate processes
o Switch system among multiple processes in the main
memory (process scheduling)
o Provides communication mechanisms so that
processes can send (or receive) data to (or from)
each other (process communication).
o Control concurrent* access to shared data to keep
shared data consistent (process synchronization).
o Allocate/de-allocate resources properly to prevent or
avoid deadlock situation**
I/O Management
• Motivations:
o Provide the abstract level of H/W devices and keep the
details from applications to ensure proper use of devices,
to prevent errors, and to provide users with convenient
and efficient programming environment.
• Tasks of I/O Management of OS:
o Hide the details of H/W devices
o Manage main memory for the devices using cache, buffer,
and spooling
o Maintain and provide device driver interfaces
Main Memory management
Process must be mapped to physical addresses and
loaded into main memory to be executed.
• Motivations:
o Increase system performance by increasing “hit” ratio
(e.g., optimum: when CPU read data or instruction, it is in
the main memory always)
o Maximize memory utilization
• Tasks of Main Memory Management of OS:
o Keep track of which memory area is used by whom.
o Allocate/de-allocated memory as need
File & Storage Management
• Motivation:
o Almost everything is stored in secondary storage.
Therefore, secondary storage access must be
efficient (i.e., performance) and convenient (i.e.,
easy to program I/O function in application level)
o Important data are duplicated and/or stored in
ternary storage.
• Tasks of File Management
o Create, manipulate, delete files and directories
• Tasks of Storage Management
o Allocate, de-allocate, and defrag blocks[1]
o Bad block marking
o Scheduling for multiple I/O request to optimize
the performance
Networking/Communications
• Allow communications between computers
(more important for Client/Server OS and
Distributed OS).
• Communications may be via shared memory
or through message passing (packets moved
by the OS)
Protection and Error Detection
• Protection
– Hardware resources, Kernel code, processes, files, and
data from erroneous programs and malicious programs.
• Error detection
– May occur in the CPU and memory hardware, in I/O
devices, and in user program
– For each type of error, OS should take the appropriate
action to ensure correct and consistent computing
– Debugging facilities can greatly enhance the user’s and
programmer’s abilities to efficiently use the system
Command Interpreter
• Command Interpreter is one of the most important
system programs[1]. Because almost every OS provide
system programs, some people argue that command
interpreter is a part of OS.
• Motivation:
o Allow human users to interact with OS
o Provide convenient programming environment to users
• Tasks:
o Execute a user command by calling one or more number of
underlying system programs or system calls
• Examples:
o Windows DOS command window
o Bash of Unix/Linux
o CSHELL of Unix/Linux
System Calls
• Programming interface to the services provided by the OS
– Typically written in a high-level language (C or C++)
– Mostly accessed by programs via a high-level Application Program
Interface (API) rather than direct system call use
• Three most common APIs are Win32 API for Windows, POSIX
API for POSIX-based systems (including virtually all versions of
UNIX, Linux, and Mac OS X), and Java API for the Java virtual
machine (JVM)
• Why use APIs rather than system calls?
Example of System Calls
• System call sequence to copy the contents
of one file to another file
Example of Standard API
• Consider the ReadFile() function in the
• Win32 API—a function for reading from a file
• A description of the parameters passed to ReadFile()
–
–
–
–
–
HANDLE file—the file to be read
LPVOID buffer—a buffer where the data will be read into and written from
DWORD bytesToRead—the number of bytes to be read into the buffer
LPDWORD bytesRead—the number of bytes read during the last read
LPOVERLAPPED ovl—indicates if overlapped I/O is being used
Types of System Calls
•
•
•
•
•
Process control
File management
Device management
Information maintenance
Communications
System Call Implementation
• Typically, a number associated with each system call
– System-call interface maintains a table indexed according to
these numbers
• The system call interface invokes intended system call in
OS kernel and returns status of the system call and any
return values
• The caller need know nothing about how the system
call is implemented
– Just needs to obey API and understand what OS will do as a
result call
– Most details of OS interface hidden from programmer by API
• Managed by run-time support library (set of functions built into
libraries included with compiler)
API – System Call – OS Relationship
Standard C Library Example
• C program
invoking printf()
library call, which
calls write()
system call
API vs. System Call summary
• An API is application programming interface
– This are a set of standard functions that the
program calls.
– This API then call the specific System call for that
specific O/S
• A system call is specific to an O/S
– The system call for an O/S may be different
between versions
• Different parameters, even different names.
Operating System Design and
Implementation
• Design and Implementation of OS not “solvable”, but
some approaches have proven successful
• Internal structure of different Operating Systems
can vary widely
• Start by defining goals and specifications
• User goals and System goals
– User goals – operating system should be convenient to
use, easy to learn, reliable, safe, and fast
– System goals – operating system should be easy to design,
implement, and maintain, as well as flexible, reliable,
error-free, and efficient
Operating System Design and Implementation
(Cont.)
• Important principle to separate
Policy: What will be done?
Mechanism: How to do it?
• Mechanisms determine how to do something,
policies decide what will be done
– The separation of policy from mechanism is a very
important principle, it allows maximum flexibility if policy
decisions are to be changed later
Simple Structure
• MS-DOS – written to provide the most
functionality in the least space
– Not divided into modules
– Although MS-DOS has some structure, its
interfaces and levels of functionality are not well
separated
MS-DOS Layer Structure
Monolithic (The big mass) O/S
• OS is simply a collection of functions, which can call
any other ones when needed.
• One very big OS including everything (system calls, system
programs, every managers, device drivers, etc)
• Entire OS resides in main memory
• Pros:
• High performance
• Easy to implement
• Cons:
• Difficult to debug, modify, and upgrade
• Poor security, protection, and stability of OS
Layered Approach
• still large single program but
internally broken up into
layers providing different
functionalities.
• Information hiding between
layers  Increased security
and protection
• Easy to debug, test, and
modify OS
• If one layer stops working,
entire system will stop
• Example:
System Calls
Memory Management
Process Scheduling
I/O Management
Device Drivers
• Mapping overhead between
layers
• Difficult to categorize into
layers
Layered Operating System
UNIX
• UNIX – limited by hardware functionality, the
original UNIX operating system had limited
structuring. The UNIX OS consists of two
separable parts
– Systems programs
– 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; a
large number of functions for one level
UNIX System Structure
Microkernel System Structure
• Moves as much from the kernel into “user” space
• OS is made up of several separated/independent modules
– kernel, FS, MM, etc and only kernel resides in main memory.
• Kernel calls other modules as needed to perform certain
tasks.
– Benefits:
•
•
•
•
Easier to extend a microkernel
Easier to port the operating system to new architectures
More reliable (less code is running in kernel mode)
More secure
– Detriments:
• Performance overhead of user space to kernel space communication
Mac OS X Structure
Modules
• Most modern operating systems implement
kernel modules
– 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
Solaris Modular Approach
Virtual Machines
• 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
Virtual Machines Cont.
• Allow multiple different OS to run on a single
machine. VM gives an illusion that the machine is at
entire disposal of OS by providing each OS an
abstract machine.
o Pros:
o Solve machine-OS-software compatibility issues.
o Stable and Good for OS development and testing (If one
OS fails, the other OS can continue to run)
o Cons:
o Complex to develop/implement
– Poor performance (abstract layer, mapping overhead
between layers, …)
Virtual Machines History and Benefits
• First appeared commercially in IBM mainframes in 1972
• Fundamentally, multiple execution environments (different
operating systems) can share the same hardware
• Protect from each other
• Some sharing of file can be permitted, controlled
• Commutate with each other, other physical systems via
networking
• Useful for development, testing
• Consolidation of many low-resource use systems onto fewer
busier systems
• “Open Virtual Machine Format”, standard format of virtual
machines, allows a VM to run within many different virtual
machine (host) platforms
Virtual Machines (Cont.)
Non-virtual Machine
Virtual Machine
(a) Nonvirtual machine (b) virtual machine
VMware Architecture
The Java Virtual Machine
Client-Server
• OS consists of servers, clients, and kernel. Kernel is
very tiny and handles only the communication
between the clients and servers. Both clients and
servers run in user mode.
o Pros:
o Stable (If a server fails, the OS can still operate)
o Small kernel
o Cons:
o Complex to develop/implement (servers run in user mode and can
access resources through kernel)
o Security problem because servers reside in user space.
Back to Design Goals
• Efficiency and Convenience
• Keep kernel adequately small
o Too much functionality in kernel  low flexibility at higher
level
o Too little functionality in kernel  low functional support
at higher level
• Maximize the utilization, performance, and
functionality of the underlying H/W resources
o OS design is affected by H/W properties
o OS design is affected by the type of system to design (e.g.,
Multiprogramming, Multi-tasking, Real-time, Distributed,
.etc)
System Generation
• We should configure OS for the underlying hardware
when we install it (i.e., installing OS)
• Approaches:
• Modify the source code of OS and recompile it on
the target machine
• Pros: small OS size, We can tune the details for the H/W
• Cons: Very difficult, less flexible for H/W upgrade
System Generation Cont.
• Provide many pre-compiled modules (e.g., five
different memory manager object files). When
we install OS, select certain object modules
and link them together accordingly.
• Pros: easy to configure, flexible for H/W upgrade
• Cons: big OS size, We cannot tune the very details
for the H/W
System Boot
• Operating system must be made available
to hardware so hardware can start it
– Small piece of code – bootstrap loader,
locates the kernel, loads it into memory, and
starts it
– Sometimes two-step process where boot
block at fixed location loads bootstrap loader
– When power initialized on system, execution
starts at a fixed memory location
• Firmware used to hold initial boot code
Q&A