Chapter 2 operating system structures
1 / 64

Chapter 2, Operating System Structures - PowerPoint PPT Presentation

  • Uploaded on

Chapter 2, Operating System Structures. 2.1 Operating System Services. Overview List: User interface Program execution File system Communications Error detection Efficiency functionality Security. User interface: Command line Batch Graphical user interface Program execution Load

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Chapter 2, Operating System Structures' - quincy-mcneil

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

2 1 operating system services
2.1 Operating System Services

  • Overview List:

    • User interface

    • Program execution

    • File system

    • Communications

    • Error detection

    • Efficiency functionality

    • Security

  • User interface:

    • Command line

    • Batch

    • Graphical user interface

  • Program execution

    • Load

    • Run

    • End successfully or not

  • I/O operations

    • Access to physical devices (usually protected—a system service)

  • File system manipulation, files, directories

    • Read, write

    • Make, delete

    • Find, navigate

  • 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.

  • 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

  • Protection and security multi-user systems

    • Logins and rwx type permissions

    • Protecting one process from another (in memory)

    • Protecting from outside intrusions

2 2 user operating system interface
2.2 User Operating System Interface multi-user systems

  • Overview List:

  • Command interpreter function

  • Command interpreter architecture

  • GUI

  • Choice of interface

  • Command interpreter function multi-user systems

    • 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

2 3 system calls
2.3 System Calls multi-user systems

  • Overview list:

    • Explicit system calls

    • Embedded system calls

    • Implicit system calls

    • Passing parameters in the system

    • System calls in Java

  • Explicit system call multi-user systems

    • 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

  • Implicit system calls multi-user systems

    • 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 multi-user systems

    • 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

  • System calls in Java multi-user systems

    • 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

2 4 types of system calls
2.4 Types of System Calls multi-user systems

  • Overview List:

    • Process control

    • File management

    • Device management

    • Information management

    • Communications

  • Process control multi-user systems

    • End, abort

    • Load, execute

    • Create, terminate

    • Get attributes, set attributes

    • Wait for time

    • Wait for event, signal event

    • Allocate and free memory

  • File management multi-user systems

    • 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

  • Information management multi-user systems

    • 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

2 5 system programs
2.5 System Programs multi-user systems

  • 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

  • Six categories (overlapping with previously presented lists) multi-user systems

    • File management

    • Status information

    • File modification

    • Programming language support (compilers, assemblers, interpreters, debuggers)

    • Program loading and execution (absolute loaders, relocatable loaders, linkers, etc.)

    • Communications

2 6 operating system design and implementation
2.6 Operating System Design and Implementation multi-user systems

  • 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

  • Parameter three: User requirements multi-user systems

    • 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.

  • Mechanisms and policies multi-user systems

  • 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

  • Examples multi-user systems

  • 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

O s implementation
O/S multi-user systemsimplementation

  • Originally: assembly language

  • Modern systems

  • ~10% assembly language

    • Context switching

    • Possibly process scheduling

    • Possibly memory management

  • ~90% C—all remaining system functionality

2 7 operating system structure
2.7 Operating System Structure multi-user systems

  • Overview List:

    • Simple structure/no structure/monolithic

    • The layered approach

    • Modular design (object-oriented)

Ms dos example
MS DOS example multi-user systems

Original unix example
Original Unix example through the software

  • The original Unix was no better through the software

  • Superficially layered

  • The layers contained lots of stuff

  • Internally the layers were undisciplined in design

The layered approach
The Layered Approach through the software

  • Design functionality from the top down (from the outside in) through the software

  • 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

  • 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

  • Microkernels into layers and getting the dependencies straight contain the bare minimum of system code

    • Process management

    • Memory management

    • Message passing

  • The kernel remains small and fast and manageable by developers

  • All other system code written into modules into layers and getting the dependencies straight

    • 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

Modular design solaris
Modular Design into layers and getting the dependencies straight(Solaris)

Object oriented design
Object-oriented into layers and getting the dependencies straightdesign

  • 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

Mac os x
Mac OS X into layers and getting the dependencies straight

2 8 virtual machines
2.8 Virtual Machines into layers and getting the dependencies straight

  • 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 mode vs. virtual user mode and real user mode vs. virtual 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

Benefits of virtual machines
Benefits of virtual machines system mode vs.

  • 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

2 9 java
2.9 Java system mode vs.

  • Java has three parts

    • Programming language specification

    • Application programming interface (API)

    • Virtual machine specification

  • Note that Java is another example of a virtual machine architecture

  • Java API editions system mode vs.

    • 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…

  • The Java Virtual Machine = JVM system mode vs.

  • 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

About the jvm
About the JVM system mode vs.

  • 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

Running a java program
Running a Java Program system mode vs.

Random additional comments
Random additional comments system mode vs.

  • 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

2 10 operating system debugging
2.10 Operating System Debugging system mode vs.

  • This section can be summarized as, “If you ever had to debug an operating system, it might be the hardest thing you ever had to do.”

  • Failure analysis and performance tuning are worthwhile concepts, but the details are unimportant

  • DTrace is of no particular consequence to us

2 11 operating system generation
2.11 Operating System Generation to start from scratch than it is to debug it

  • System generation = installing and setting up an O/S on a machine

  • Most O/S’s can function on multiple hardware platforms

  • Installation requires setting parameters: to start from scratch than it is to debug it

    • 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.

  • O/S performance parameters to start from scratch than it is to debug it

    • Ease and speed of installation and set-up

    • Performance speed and memory size at run time

    • Ease of modification

  • Ease of modification to start from scratch than it is to debug it

    • Most systems probably have elements of both:

      • Major modifications: Change settings, recompile, reinstall

      • Minor modifications: Change settings from table options on the fly

2 12 system boot
2.12 System Boot to start from scratch than it is to debug it

  • Already covered while going over chapter 1

The end
The End to start from scratch than it is to debug it