Transcript Slide 1

Chapter 2, Operating System
Structures
1
2.1 Operating System Services
• Overview List:
– User interface
– Program execution
– File system
– Communications
– Error detection
– Efficiency functionality
– Security
2
• User interface:
– Command line
– Batch
– Graphical user interface
• Program execution
– Load
– Run
– End successfully or not
3
• I/O operations
– Access to physical devices (usually protected—a
system service)
• File system manipulation, files, directories
– Read, write
– Make, delete
– Find, navigate
4
• Communications
–
–
–
–
Inter-process communication
Same computer or different systems
Message passing
Or shared memory
• Error detection
–
–
–
–
In CPU
In memory
In user program
Detect and handle gracefully, allowing continued use
of the system.
5
• O/S functions to promote efficiency, especially on
multi-user systems
– Resource allocation
•
•
•
•
Scheduling CPU cycles
memory access
I/O
file system, etc.
– Accounting
•
•
•
•
How much of each resource used by each user
In what pattern
At what times
Billling and system configuration
6
• Protection and security
– Logins and rwx type permissions
– Protecting one process from another (in memory)
– Protecting from outside intrusions
7
2.2 User Operating System Interface
•
•
•
•
•
Overview List:
Command interpreter function
Command interpreter architecture
GUI
Choice of interface
8
• Command interpreter function
– Setup for a command line interface
– Gives the prompt
– Takes in the command and takes action
• Command interpreter architecture
–
–
–
–
May be part of the kernel
May be run as a separate program
May include the code to be run as subroutines
May call separate system programs based on the
command entered
9
• GUI—no important new information here
• Choice of interface
– User preference
– Note power of programming in a command line
interface vs. a GUI
10
2.3 System Calls
• Overview list:
– Explicit system calls
– Embedded system calls
– Implicit system calls
– Passing parameters in the system
– System calls in Java
11
• Explicit system call
– Example: copying a file
– Entered from command line or through GUI
– One user system call may result in a sequence of
internal system calls
• Embedded system call
– In ASM, C, C++, etc., it is possible to include lines
of code containing system calls
12
• Implicit system calls
– The compiler translates user instructions to
machine instructions
– At run time, machine instructions which are
protected trigger system calls
– The classic example is file I/O
13
• Passing parameters in the system
– Stored in registers
– Stored in memory, memory address stored in
register
– Pushed onto the stack
• Note that this heading is relevant to the topic
of system calls
• Various system calls require that parameters
be passed when (before) the call is made
14
• System calls in Java
– Write a method in Java declared “native”
– Let the native method be a holder for C or C++
(system language) code
– The C/C++ code can call system programs
– Note that the Java code is now platform
dependent, not portable
15
2.4 Types of System Calls
• Overview List:
– Process control
– File management
– Device management
– Information management
– Communications
16
• Process control
– End, abort
– Load, execute
– Create, terminate
– Get attributes, set attributes
– Wait for time
– Wait for even, signal event
– Allocate and free memory
17
• File management
–
–
–
–
Create, delete
Open, close
Read, write, reposition
Get attributes, set attributes
• Device management
–
–
–
–
Request, release
Read, write, reposition
Get attributes, set attributes
Logically attach or detach
18
• Information management
–
–
–
–
Get time or date, set time or date
Get system data, set system data
Get process, file, or device attributes
Set process, file, or device attributes
• Communications
–
–
–
–
Create, delete communication connection
Send, receive messages
Transfer status information
Attach or detach remote devices
19
2.5 System Programs
• Representative of O/S code that’s not in the
kernel
• Some items are interfaces to call system
services
• Some are distinct system programs or
collections of programs
20
• Six categories (overlapping with previously
presented lists)
–
–
–
–
File management
Status information
File modification
Programming language support (compilers,
assemblers, interpreters, debuggers)
– Program loading and execution (absolute loaders,
relocatable loaders, linkers, etc.)
– Communications
21
2.6 Operating System Design and
Implementation
• Overview List:
– Parameter 1: What kind of hardware?
– Parameter 2: What kind of system?
– Parameter 3: User requirements
– Parameter 4: Developer requirements
– Mechanisms and policies
– Examples
– O/S implementation
22
• Parameter one: What kind of hardware?
• Parameter two: What kind of system?
– Single user
– Multi-user
– Distributed
– Real-time, etc.
23
• Parameter three: User requirements
– Easy to learn, use, etc.
– Fast, safe, reliable, etc.
– Note that there is no obvious connection between
these requirements and how you code the system
in order to meet them
• Parameter four: Developer requirements
– Easy to design, implement, maintain, etc.
24
• Mechanisms and policies
• Software design principle, separate the two
– Policy = what to do
– Mechanism = how to do it
• In other words, don’t hardcode policy
• Implement mechanisms that can enforce
different policies depending on input
parameters
25
• Examples
• Unix
– The micro-kernel can support batch, time-sharing,
real-time, or any combination
– What is supported depends on values in tables loaded
at start-up
• Windows takes the opposite approach
– Mechanism and policy are tightly coupled
– The system is relatively inflexible
– There is a reason for this: It enforces the same look
and feel across all installations
26
•
•
•
•
O/S implementation
Originally: assembly language
Modern systems
~10% assembly language
– Context switching
– Possibly process scheduling
– Possibly memory management
• ~90% C—all remaining system functionality
27
2.7 Operating System Structure
• Overview List:
– Simple structure/no structure/monolithic
– The layered approach
– Modular design (object-oriented)
28
• Simple structure = not well structured
– Simple systems that grew without a plan
– Systems where immediate performance needs
were paramount
– Monolithic systems in general
29
MS DOS example
30
• The left hand set of arrows represents a
layered path through the software
• The right-hand, non-layered path enabled
performance, but made the system errorprone
31
Original Unix example
32
•
•
•
•
The original Unix was no better
Superficially layered
The layers contained lots of stuff
Internally the layers were undisciplined in
design
33
The Layered Approach
34
• Design functionality from the top down (from the
outside in)
• Code and debug from the bottom up (from the inside
out)
• Each layer has data structures, code, and interface
• The implementation of the layers can change as long as
the interface discipline is maintained
• Somewhat object-oriented
• Less general because each layer interacts with two
neighbors only
35
• The fundamental challenge of layered systems is
breaking it into layers and getting the
dependencies straight
• Each upper layer can only be implemented with
calls to its lower neighbor
• Sorting this out in the kernel is not trivial. Which
is lowest, process scheduling, memory
management, or some other function?
• The practical disadvantage of layering is the
performance cost of going down through the
layers
36
• Microkernels contain the bare minimum of
system code
– Process management
– Memory management
– Message passing
• The kernel remains small and fast and
manageable by developers
37
• All other system code written into modules
– Modules run like user applications
– But they are privileged to make system calls
– Communication between them is managed by the
kernel
• All other system programs can be changed
without affecting the kernel
38
Modular Design (Solaris)
39
• Object-oriented design
• Kernel and other modules can be dynamically
loaded and linked to provide needed services
• Different objects/modules can communicate
with each other
• Modern Unix systems take this approach
40
Mac OS X
41
• BSD = Berkeley Standard Distribution (kernel)
• Mach = Carnegie Mellon (micro-kernel)
• Different O/S functions are handled by the
two
• Mac OS X is a hybrid system
42
2.8 Virtual Machines
• Logical conclusion of multi-user, multi-tasking
• Logical conclusion of layering idea
• Each user has access to a simulated hardware
interface
• Each user can load a different O/S, access
different virtual peripherals, etc.
43
• The challenge in implementation is keeping track
of real system mode vs. user mode and virtual
system mode vs. user mode
• With only one underlying machine there is only
one real system mode, but there are many virtual
system modes, one for each virtual machine
• Sharing and communication between virtual
machines is also an important challenge in
implementation
• A diagram follows
44
45
Benefits of virtual machines
• Users can run different O/S’s
• Users are completely isolated from each other
• System developers can work on O/S and other
system code on one virtual machine while users
run on the others
• The original VM system—IBM mainframe—now
configured to run Linux as well as CMS
• VMware runs on Intel systems, making it possible
to load >1 O/S on a system at a time
46
2.9 Java
• Java has three parts
– Programming language specification
– Application programming interface (API)
– Virtual machine specification
47
• Programming language characteristics
– Object-oriented
– Architecture neutral
– Distributed
– Multi-threaded
– Secure
– With automatic garbage collection
48
• Java API editions
– JSE = standard edition
• Desktop applications and network applets
• Graphics, I/O, security, db connectivity, networking
– EE = enterprise edition
• Server applications with db support
– ME = micro edition
• Applications on phones, pagers, handheld devices…
49
• The Java Virtual Machine = JVM
• The Java platform =
– An implementation of the JVM specification for
any given hardware environment
– Plus the Java API
• The Java platform can be implemented
– On top of a host O/S
– In a browser
– Or the JVM can be implemented in hardware
50
About the JVM
• In a software environment, when main() is called in an
application, this causes an instance of the JVM to be
created
• Each separate application or applet in execution has its
own JVM
• The JVM consists of a loader and an interpreter. The
loader loads a .class file containing Java byte code
• The interpreter, or just in time compiler, translates Java
code into the commands and calls necessary in a given
environment
• Implementations of the JVM differ across
environments, but not the specification
51
Running a Java Program
52
Random additional comments
• For development purposes a Java Development
Environment would consist of a compiler plus a
Java Runtime Environment (JRE)
• In theory you might write an O/S with a
microkernel in C/ASM and the rest in Java, using
Java’s type safety mechanism for security. JX is an
example
• The MS .NET framework is similar to the Java
approach
53
2.10 Operating System Generation
• System generation = installing and setting up
an O/S on a machine
• Most O/S’s can function on multiple hardware
platforms
54
• Installation requires setting parameters:
– What CPU, how many, which instruction set(s)?
– How much main memory?
– What attached devices, type and model,
numerical designation, interrupt number
– O/S parameters: scheduling algorithm, number of
I/O buffers, number of processes allowed, etc.
55
• Approaches to system generation fall into a
range:
– Set parameters in source, compile O/S, install
– Select precompiled modules from libraries
– Table driven—select options after O/S is up and
running
56
• O/S performance parameters
– Ease and speed of installation and set-up
– Performance speed and memory size at run time
– Ease of modification
57
• Ease of modification
– Most systems probably have elements of both:
• Major modifications: Change settings, recompile,
reinstall
• Minor modifications: Change settings from table
options on the fly
58
2.11 System Boot
• Already covered while going over chapter 1
59
The End
60