1 / 35

School of Computing Science Simon Fraser University CMPT 300: Operating Systems I

School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 2: Operating System Structures Dr. Mohamed Hefeeda. Objectives. Describe services provided by OS to users, processes, and other systems Discuss various ways of structuring OS

lpeach
Download Presentation

School of Computing Science Simon Fraser University CMPT 300: Operating Systems I

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. School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 2: Operating System Structures Dr. Mohamed Hefeeda

  2. Objectives • Describe services provided by OS to users, processes, and other systems • Discuss various ways of structuring OS • Explain customization of OS for different machines and how OS boots

  3. Operating System Services • OS provides two sets of services • One for user convenience • Another for efficient use of resources

  4. OS Services: User Convenience • User interface • Command-Line Interface (CLI) or Graphics User Interface (GUI) • Program execution • load program into memory and run it • end execution, either normally or abnormally • I/O operations • programs may require I/O, which may involve a file or an I/O device • File-system manipulation • programs may need to do the following on files/directories … • read, write • create, delete • search, list file Information • permission management

  5. OS Services: User Convenience (cont’d) • Communications • Processes may exchange information, on the same computer or between computers over a network • Error detection • OS needs to be constantly aware of possible errors • May occur in CPU and memory hardware, in I/O devices, in user program • For each type of error, OS should take the appropriate action to ensure correct and consistent computing • Debugging facilities can greatly enhance the user’s and programmer’s abilities to efficiently use the system

  6. OS Services: Efficient Use of Resources • Resource allocation • When multiple users or multiple jobs running concurrently, resources must be allocated to each of them • Accounting • To keep track of which users use how much and what kinds of computer resources • Protection and security • OS should provide secure and protected access to data • Protection: involves ensuring that all access to system resources is controlled • Security: of the system from outsiders requires user authentication

  7. User-OS Interface: CLI • CLI allows direct command entry • Implemented in kernel or as a systems program • Called shell • Multiple flavors (shells) may exist • Function: get a command from user and execute it • Command could be: built-in or user programs • Example shells: • bash, csh, tcsh, …

  8. User-OS Interface: GUI • User-friendly desktop metaphor interface • Usually mouse, keyboard, and monitor • Icons represent files, programs, actions, etc • Various mouse buttons over objects in the interface cause various actions (provide information, options, execute function, open directory (known as a folder) • Invented at Xerox PARC • Many systems now include both CLI and GUI • Microsoft Windows is GUI with CLI “command” shell • Apple Mac OS X has “Aqua” GUI interface with UNIX kernel underneath and shells available • Solaris is CLI with optional GUI interfaces (Java Desktop, KDE)

  9. System Calls • How can we access OS services? • System calls • A programming interface to OS services • Typically written in high-level language (C or C++) • Mostly accessed by programs via a high-level Application Program Interface (API), rather than direct system call • Why use APIs rather than direct system calls? • Portability • Ease • Three most common APIs • Win32 API for Windows • POSIX API for POSIX-based systems (UNIX, Linux, and Mac OS X) • Java API for the Java virtual machine (JVM)

  10. System Calls: Example • System call sequence to copy contents of a file to another

  11. Example: strace on Linux • Try the following commands on a Linux machine: • $ strace -c ls • Displays summary info on system calls invoked during the execution of the command ‘ls’ • $ strace –o trace.out ls • Details of the invoked system calls during the execution of the command ‘ls’ are saved in the file ‘trace.out’ • $ man strace • Displays info (manual) on strace

  12. System Call Implementation • Typically • A number is associated with each system call • System call interface maintains table indexed based on these numbers • System call interface invokes intended system call in OS kernel and returns status of system call and any return values • The caller need know nothing about how the system call is implemented • Just need to obey API and understand what OS will do as a result call • Most details of OS interface hidden from programmer by API • Managed by run-time support library (set of functions built into libraries included with compiler)

  13. API – System Call – OS Relationship

  14. Example: Standard C Library • C program invoking printf() library call, which calls write() system call

  15. System Call: Parameter Passing • Often, more information is required than simply identity of desired system call • Exact type and amount of information vary according to OS and call • Three methods to pass parameters to OS • Simplest: pass the parameters in registers • In some cases, may be more parameters than registers • Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register • This approach taken by Linux and Solaris • Parameters placed, or pushed, onto the stack by the program and popped off the stack by OS • Note: Block and stack methods do not limit the number or length of parameters being passed

  16. Types of System Calls • Process control • Create, load, execute, abort, … • File management • Open, close, read, write, delete, … • Device management • Read, write, request, release, … • Information maintenance • Get time/date, get process attributes, … • Communications • Send, receive, create communication channel, ….

  17. System Programs • System programs provide a convenient environment for program development/execution • Most users’ view of OS is defined by system programs, not the actual system calls • Examples: • File management: create, copy, delete, list, … • File modification: text editors, search, … • Status info: disk space, memory usage, CPU utilization, • Try: $top, $ps, $du, $df, $who • Programming language support: compilers, debuggers, … • Check out $man gdb (Gnu Debugger) • Communications: email, web browser, remote log in, .. • Check out: $pine • Application programs: database engine, spread sheet

  18. OS Design and Implementation • Internal structure of different OS can vary widely • Affected by choice of hardware, type of system • Guideline: • Start by defining goals and specifications • User goals vs. System goals • User goals – OS should be convenient to use, easy to learn, reliable, safe, and fast • System goals – OS should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient

  19. OS Design and Implementation (cont’d) • Important principle:Separate Policy from Mechanism • What is policy and what is mechanism? • Policy decides what will be done • Mechanism determines how to do it • Why separation? • Allows maximum flexibility if policy decisions are to be changed later • Example • Policy: CPU-intensive programs get higher priority over I/O-intensive ones • Mechanism: implement a priority system with different levels

  20. Operating System Structure • How would you structure a complex system like OS? • Simple • monolithic (one layer) or some layering but no clear interfaces • Layered • Microkernel • Modular • Virtual Machines

  21. Simple Structure: Old UNIX • Monolithic structure: two parts • Systems programs • Kernel: everything below system-call interface and above hardware • File system, CPU scheduling, memory management, …. • Difficult to implement and maintain: Too much in one layer

  22. Simple Structure: MS-DOS • MS-DOS – written to provide the most functionality in the least space • Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated • No protection • Apps crash whole system • Limited by hardware at that time

  23. Layered Structure • OS is divided into layers • Each layer uses services of only lower-level layers • Easy to develop, debug, and update: Focus on one layer at a time • Problems with layering? • Less efficient: every layer adds some overhead • Tricky to define layers • Ex: two layers that need each other’s services • CPU scheduler and backing-store driver

  24. Microkernel Structure • Kernel provides minimal services: • Process and memory management, and communication facility • Rest of services are moved to user space • Communication takes place between user modules using message passing (through the kernel) • Benefits: • Easier to extend microkernel • Easier to port the operating system to new architectures • More reliable and secure • Less code is running in kernel mode, most are user mode ==> service fails, the rest of OS is untouched • Disadvantages: • Performance overhead: communication among user modules and the kernel

  25. Modular Structure • Implement OS as separate components (modules) • Each module has a well-defined interface • Modules talk to each other using interfaces • Modules are loaded within the kernel when needed • Most modern OSes (e.g., Solaris, Linux) implement kernel modules

  26. Modular Structure: Solaris

  27. Modular Structure: Advantages? • Similar to layers but more flexible • Avoids the problem of defining layers • Easy to maintain, update, and debug: focus on one module at a time • Efficient: modules can call each others directly (no layers in between and no message passing)

  28. Hybrid Structure: Mac OS X • Layered approach with one layer as a microkernel • Mach provides: memory management, RPC, IPC, scheduling • BSD provides: file system, CLI, networking, APIs • Allows for kernel extensions (loadable modules)

  29. Virtual Machines • Virtual machine abstracts hardware of a single computer into several different execution environments (OSes) • Resources are shared to create virtual machines • CPU scheduling and virtual-memory techniques help to create the illusion that users have their own processors and memory • Examples • VMware • Java Virtual Machine

  30. Example: VMware Architecture

  31. Virtual Machines (cont’d) • Why VMs? • OS research and development • Test OS on VMs with various configurations • Safer, faster, and cost-effective to test on VMs • VMs provide complete protection of system resources • Each virtual machine is isolated from all others

  32. Operating System Configuration • Do we develop OSes on machines that run them? • NO! Usually develop on a machine and run on another • Think of OS for cell phones or slow/small computers • How would we customize OS for a target machine? • Get information about target machine • e.g., CPU, memory, hard drive, I/O devices attached • Save this info in configuration files • THEN: ??

  33. Operating System Configuration (cont’d) • Recompile OS code with configuration files • Tailor OS precisely for target machine • Efficient OS, but not flexible and recompilation takes time; OR • Load or link modules based on configuration files • Modules (e.g., device drivers) are precompiled • Fast configuration, produce fairly general systems  less efficient; OR • Select during run time • Kernel contains code for all supported configurations • Selection occurs at execution time • flexible, but large kernel • When would you use each of these methods?

  34. System Boot • OS must be available to hardware to start it • When computer is powered up, the instruction register is loaded with a predefined memory location • Typically, the address of the bootstrap loader in ROM • Bootstrap loader routine • Performs diagnostic tests (Power-on Self Testing) • Loads a small piece of code from a fixed location (block 0) on the disk into memory, which • loads the rest of the loader from disk, which • loads kernel itself • Examples: • LiLo (Linux Loader) and Grub

  35. Summary • OS provides two sets of services for • user convenience and • efficient use of resources • OS-user interface: CLI (shells) or GUI (windows) • System calls: interface to OS services • Typically used through APIs for portability and ease • OS design: specify requirements, separate policies from mechanisms • OS structure: simple, layered, microkernel, modular, VM • OS configuration and boot

More Related