1 / 64

Chapter 2, Operating System Structures

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

quincy-mcneil
Télécharger la présentation

Chapter 2, Operating System Structures

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 2, Operating System Structures

  2. 2.1 Operating System Services • Overview List: • User interface • Program execution • File system • Communications • Error detection • Efficiency functionality • Security

  3. User interface: • Command line • Batch • Graphical user interface • Program execution • Load • Run • End successfully or not

  4. I/O operations • Access to physical devices (usually protected—a system service) • File system manipulation, files, directories • Read, write • Make, delete • Find, navigate

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

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

  7. Protection and security • Logins and rwx type permissions • Protecting one process from another (in memory) • Protecting from outside intrusions

  8. 2.2 User Operating System Interface • Overview List: • Command interpreter function • Command interpreter architecture • GUI • Choice of interface

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

  10. GUI—no important new information here • Choice of interface • User preference • Note power of programming in a command line interface vs. a GUI

  11. 2.3 System Calls • Overview list: • Explicit system calls • Embedded system calls • Implicit system calls • Passing parameters in the system • System calls in Java

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

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

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

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

  16. 2.4 Types of System Calls • Overview List: • Process control • File management • Device management • Information management • Communications

  17. Process control • End, abort • Load, execute • Create, terminate • Get attributes, set attributes • Wait for time • Wait for event, signal event • Allocate and free memory

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

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

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

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

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

  23. Parameter one: What kind of hardware? • Parameter two: What kind of system? • Single user • Multi-user • Distributed • Real-time, etc.

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

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

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

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

  28. 2.7 Operating System Structure • Overview List: • Simple structure/no structure/monolithic • The layered approach • Modular design (object-oriented)

  29. Simple structure = not well structured • Simple systems that grew without a plan • Systems where immediate performance needs were paramount • Monolithic systems in general

  30. MS DOS example

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

  32. Original Unix example

  33. The original Unix was no better • Superficially layered • The layers contained lots of stuff • Internally the layers were undisciplined in design

  34. The Layered Approach

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

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

  37. Microkernels contain the bare minimum of system code • Process management • Memory management • Message passing • The kernel remains small and fast and manageable by developers

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

  39. Modular Design (Solaris)

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

  41. Mac OS X

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

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

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

  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 • Note that Java is another example of a virtual machine architecture

  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

More Related