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 Explain customization of OS for different machines and how OS boots

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

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

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

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

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

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)

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)

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

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

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)

API – System Call – OS Relationship

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

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

Types of System Calls Process control File management 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, ….

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

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

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

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

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

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

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

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

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

Modular Structure: Solaris

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)

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)

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

Example: VMware Architecture

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

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: ??

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? In some of your projects, you will Modify the Linux kernel and compile on a Linux machine and test on another machine with different configurations (the VM running on WinXP) Configurations are defined in .config file

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

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