School of Computing Science

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 (contd)

• 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
  users and programmers 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 (contd)

• 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 others 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 gt 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 (contd)

• 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 (contd)

• 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