620 likes | 723 Vues
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
E N D
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 • Logins and rwx type permissions • Protecting one process from another (in memory) • Protecting from outside intrusions
2.2 User Operating System Interface • Overview List: • Command interpreter function • Command interpreter architecture • GUI • Choice of 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
GUI—no important new information here • Choice of interface • User preference • Note power of programming in a command line interface vs. a GUI
2.3 System Calls • Overview list: • Explicit system calls • Embedded system calls • Implicit system calls • Passing parameters in the system • System calls in Java
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
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 • 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 • 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 • Overview List: • Process control • File management • Device management • Information management • Communications
Process control • End, abort • Load, execute • Create, terminate • Get attributes, set attributes • Wait for time • Wait for even, signal event • Allocate and free memory
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
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
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
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
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
Parameter one: What kind of hardware? • Parameter two: What kind of system? • Single user • Multi-user • Distributed • Real-time, etc.
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.
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
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
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
2.7 Operating System Structure • Overview List: • Simple structure/no structure/monolithic • The layered approach • Modular design (object-oriented)
Simple structure = not well structured • Simple systems that grew without a plan • Systems where immediate performance needs were paramount • Monolithic systems in general
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 error-prone
The original Unix was no better • Superficially layered • The layers contained lots of stuff • Internally the layers were undisciplined in design
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
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 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 • 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
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
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
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.
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
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
2.9 Java • Java has three parts • Programming language specification • Application programming interface (API) • Virtual machine specification
Programming language characteristics • Object-oriented • Architecture neutral • Distributed • Multi-threaded • Secure • With automatic garbage collection
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…
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