Transcript Slide 1

Chapter 2, Operating System
Structures
1
2.1 Operating System Services
• User interface:
– Command line
– Batch
– Graphical user interface
• Program execution
– Load
– Run
– End successfully or not
2
• I/O operations
– Access to physical devices (usually protected—a
system service)
• File system manipulation, files, directories
– Read, write
– Make, delete
– Find, navigate
3
• 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.
4
• 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
5
• Protection and security
– Logins and rwx type permissions
– Protecting one process from another (in memory)
– Protecting from outside intrusions
6
2.2 User Operating System Interface
• 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
7
• GUI—no important new information here
• Choice of interface
– User preference
– Note power of programming in a command line
interface vs. a GUI
8
2.3 System Calls
• 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
9
• 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
• Passing parameters in the system
– Stored in registers
– Stored in memory, memory address stored in register
– Pushed onto the stack
10
• 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
11
2.4 Types of System Calls
• Process control
– End, abort
– Load, execute
– Create, terminate
– Get attributes, set attributes
– Wait for time
– Wait for even, signal event
– Allocate and free memory
12
• 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
13
• 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
14
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
15
• 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
16
2.6 Operating System Design and
Implementation
• Parameter one: What kind of hardware?
• Parameter two: What kind of system?
– Single user
– Multi-user
– Distributed
– Real-time, etc.
17
• 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.
18
• 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
19
• 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
20
•
•
•
•
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
21
2.7 Operating System Structure
• Simple structure = not well structured
– Simple systems that grew without a plan
– Systems where immediate performance needs
were paramount
– Monolithic systems in general
22
MS DOS example
23
• 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
24
Original Unix example
25
•
•
•
•
The original Unix was no better
Superficially layered
The layers contained lots of stuff
Internally the layers were undisciplined in
design
26
The Layered Approach
27
• Design functionality from the top down
• Debug from the bottom up
• 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
28
• 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
29
• Microkernels contain the bare minimum of system code
– Process management
– Memory management
– Message passing
• 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
• The kernel remains small and fast and manageable by
developers
• All other system programs can be changed without
affecting the kernel
30
Modular Design
31
• 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
32
Mac OS X
33
• 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
34
2.8 Virtual Machines
35
•
•
•
•
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.
• The challenge in implementation is keeping track of
real system vs. user mode and virtual system vs. user
mode
• Sharing and communication between virtual machines
is also important
36
•
•
•
•
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
37
2.9 Java
• Java has three parts
– Programming language specification
– Application programming interface
– Virtual machine specification
38
Programming language characteristics
Object-oriented
Architecture neutral
Distributed
Multi-threaded
Secure
With automatic garbage collection
39
• Programming language characteristics
– Object-oriented
– Architecture neutral
– Distributed
– Multi-threaded
– Secure
– With automatic garbage collection
40
• 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…
41
• 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
42
• 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
43
44
• 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
45
2.10 Operating System Generation
• System generation = installing and setting up an
O/S on a machine
• Most O/S’s can fun on multiple hardware
platforms
• 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.
46
• 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
47
•
•
•
•
O/S performance parameters
Ease and speed of installation and set-up
Performance speed and memory size at run time
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
48
2.11 System Boot
• Already covered while going over chapter 1
49