Chapter 2: Operating-System Structures

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne

Operating Systems
Chapter 2
Dr. Sohail Abbas
 Chapter 2: Operating System Structures

Objectives
 To describe the services an operating system
provides to users, processes, and other
systems

 To discuss the various ways of structuring an

operating system

 To explain how operating systems are installed

and customized and how they boot
1501352 - Operating Systems 3
 Operating System Services
 Operating systems provide an environment for execution of
programs and services to programs and users

1501352 - Operating Systems 4

 Operating System Services
 One set of operating-system services provides functions that
are helpful to the user:
o Program execution - The system must be able to load a program into
memory and to run that program, end execution, either normally or
abnormally (indicating error)
o I/O operations - A running program may require I/O, which may involve
a file or an I/O device
o File-system manipulation - Programs need to read and write files and
directories, create and delete them, search them, list file Information,
permission management.

1501352 - Operating Systems 5

 Operating System Services (Cont.)
o Communications – Processes may exchange information, on the same
computer or between computers over a network
 Communications may be via shared memory or through message passing
(packets moved by the OS)
o Error detection – OS needs to be constantly aware of possible errors
 Error may occur in the CPU, memory, I/O devices, or in user program
 For each type of error, OS should take the appropriate action to ensure
correct and consistent computing

1501352 - Operating Systems 6

 Operating System Services (Cont.)
 Another set of OS functions exists for ensuring the
efficient operation of the system itself via resource
sharing
o Resource allocation - When multiple users or multiple jobs running
concurrently, resources must be allocated to each of them
 Many types of resources - such as CPU cycles, main memory, and file storage
o Accounting - To keep track of which users use how much and what
kinds of computer resources
o Protection and security - The owners of information stored in a
multiuser or networked computer system may want to control use
of that information, concurrent processes should not interfere with
each other
 Protection involves ensuring that all access to system resources is controlled
 Security of the system from outsiders requires user authentication, extends
to defending external I/O devices from invalid access attempts

1501352 - Operating Systems 7

 User Interface - CLI
 User interface - Almost all operating systems have a user interface
(UI).
Varies between Command-Line (CLI), Graphics User
Interface (GUI), Batch

 CLI or command interpreter allows direct

command entry
Sometimes implemented in kernel, sometimes by
systems program
Sometimes multiple flavors implemented – shells
Primarily fetches a command from user and executes it
– Sometimes commands built-in, sometimes just names of
programs 1501352 - Operating Systems 8

»
Bourne Shell Command Interpreter

1501352 - Operating Systems 9

 User Interface - GUI

 User-friendly desktop metaphor interface

o Usually mouse, keyboard, and monitor
o Icons represent files, programs, actions, etc
o Various mouse buttons over objects in the interface cause various
actions (provide information, options, execute function, open
directory (known as a folder)
o Invented at Xerox PARC

 Many systems now include both CLI and GUI interfaces

o Microsoft Windows is GUI with CLI “command” shell
o Apple Mac OS X is “Aqua” GUI interface with UNIX kernel
underneath and shells available
o Unix and Linux have CLI with optional GUI interfaces (CDE, KDE,
GNOME)
1501352 - Operating Systems 10
 Touchscreen Interfaces
 Touchscreen devices require new interfaces
o Mouse not possible or not desired
o Actions and selection based on gestures
o Virtual keyboard for text entry

1501352 - Operating Systems 11

The Mac OS X GUI

1501352 - Operating Systems 12

 System Calls
 Programming interface to the services provided by the OS
o Typically written in a high-level language (C or C++)
 Mostly accessed by programs via a high-level Application
Programming Interface (API) rather than direct system call use
 Behind the scenes, the functions that make up an API typically invoke
the actual system calls on behalf of the application programmer.
 System call is interface to OS services whereas the API is interface to
the system calls [for the ease of programmers].
o For example, the Windows function CreateProcess() actually
invokes the NTCreateProcess() system call in the Windows kernel.
User => Program => API => System calls => OS services => H/W

1501352 - Operating Systems 13

 System Calls

 Three most common APIs are

o Win32 API for Windows,
o POSIX (Portable Operating System Interface) API for POSIX-based
systems (including virtually all versions of UNIX, Linux, and Mac OS
X),
o Java API for the Java virtual machine (JVM)

1501352 - Operating Systems 14

 System Calls

 Why use APIs rather than system calls directly?

o program portability: program using an API may

compile and run on any system that supports the
same API (How?)

o Ease of Use: actual system calls can often be more

detailed and difficult to work with than the API
available to an application programmer

(Note that the system-call names used

throughout this text are generic)
1501352 - Operating Systems 15
 System Call Implementation
 Typically, a number associated with each system call
o System-call interface maintains a table indexed according to
these numbers
 The system call interface invokes the intended system call in
OS kernel and returns status of the system call and any return
values
 The caller needs to know nothing about how the system call is
implemented
o Just needs to obey API and understand what OS will do as a
result of a call
o Most details of OS interface are hidden from programmer by API
 Managed by run-time support library (set of functions built into libraries
included with compiler)

1501352 - Operating Systems 16

API – System Call – OS Relationship

1501352 - Operating Systems 17

 Standard C Library Example
 C program invoking printf()
library call, which calls write()
system call.
 The C library takes the value
returned by write() and
passes it back to the user
program.

1501352 - Operating Systems 18

 System Call Parameter Passing

 Often, more information is required than simply identity

of desired system call
o Exact type and amount of information vary according to OS
and call
 Three general methods used to pass parameters to the
OS
1. Simplest: pass the parameters in registers
 In some cases, may be more parameters than registers
2. 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
3. Parameters placed, or pushed, onto the stack by the program
and popped off the stack by the operating system
1501352 - Operating Systems 19
Parameter Passing via Table

1501352 - Operating Systems 20

Examples of Windows and Unix System Calls

1501352 - Operating Systems 21

 Operating-System Operations
 Due to multiprogramming, various problems may occur,
o infinite loop, processes modifying each other or the operating system
 Solution: The Dual-mode operation – which allows OS to protect itself and
other system components
o User mode and kernel mode [how to implement?]
o Mode bit provided by hardware
Provides ability to distinguish when system is running user code or
kernel code
Some instructions designated as privileged, only executable in kernel
mode
System call changes mode to kernel, return from call resets it to user
See example on next slide
 CPUs support for multi-mode operations is needed (using more than 1 bit for
mode)
 An alternative to modes, the Intel 64 family of CPUs supports four privilege
levels
1501352 - Operating Systems 26
 Example of Timer
 Timer: to prevent infinite loop / process dominating resources for
long time

 Instructions that modify the content of the timer are privileged

 Initialize a counter with the amount of time that a program is

allowed to run

o A timer is set to interrupt CPU after a specified period (fixed or

variable)
o OS decrements counter, when reaches zero, generates an interrupt
o If the timer interrupts, control transfers automatically to the OS,
which may treat the interrupt as a fatal error or may give the program
more time
1501352 - Operating Systems 27
Transition from User to Kernel Mode

1501352 - Operating Systems 28

 Operating System Design and Implementation
 Design and Implementation of OS is considered to be not “solvable”, but
some approaches have proven successful
 Internal structure of different Operating Systems can vary widely
 Start by defining goals and specifications
 The design of the system will be affected by the choice of hardware and the
type of system: desktop/laptop, mobile, distributed, or real time..

1501352 - Operating Systems 29

 Design Goals
 Requirements: User goals and System goals
o User goals – operating system should be convenient to use, easy to
learn, reliable, safe, and fast
o System goals – operating system should be easy to design, implement,
and maintain, as well as flexible, reliable, error-free, and efficient

 Flexible: easy to add or remove, plug and play, etc.

 Error-free: free of bugs usually in short term
 Reliable: error-free in a long run
 Efficient: in space and time (also response time, resource utilization)

1501352 - Operating Systems 30

 Mechanism and Policies

 Designing an OS is highly creative task of software engineering

 Important principle to separate

Policy: What will be done?
Mechanism: How to do it?

 Mechanisms determine how to do something; policies decide what will be

done
o For example, the timer construct is a mechanism for ensuring CPU
protection, but deciding how long the timer is to be set for a
particular user is a policy decision.
o The separation of policy from mechanism is a very important
principle, it allows maximum flexibility if policy decisions are to be
changed later.

1501352 - Operating Systems 31

 Implementation
 Much variation
o Early OSes in assembly language
o Then system programming languages like Algol, PL/1
o Now C, C++
 Usually, a mix of languages
o Lowest levels in assembly
o Main body in C
o Systems programs in C, C++, scripting languages like PERL, Python, or
using shell scripts
 Implementation in high-level language
o to port to other hardware
o Fast production, compact code, easy to understand and debug.
o But slower
 Operating systems may be developed using emulators of the target
hardware, particularly if the real hardware is unavailable ( or not built yet )
1501352 - Operating Systems 32
 Virtualization vs. Emulation
 The purpose of an emulator is to accurately reproduce the behavior of some
hardware.
 The purpose of a virtual machine is to create an isolated environment.

Examples
 Emulation, in short, involves making one system imitate another. For
example, if a piece of software runs on system A and not on system B, we
make system B “emulate” the working of system A. The software then runs
on an emulation of system A.
 In this same example, virtualization would involve taking system A and
splitting it into two servers, B and C. Both of these “virtual” servers are
independent software containers, having their own access to software
based resources – CPU, RAM, storage and networking – and can be
rebooted independently.
 The servers do not know that we are running in an abstract environment.

1501352 - Operating Systems 33

 Operating System Structure
 General-purpose OS is very large
program
 Various ways to structure one as follows

Simple Structure
 I.e. MS-DOS – written to provide the
most functionality in the least space
o Not divided into modules
o Although MS-DOS has some structure, its
interfaces and levels of functionality are
not well separated
o Application programs are able to access
the basic I/O routines, hence, cause
system crashes (but it was due to no
support from the h/w).
1501352 - Operating Systems 34
 UNIX

 UNIX – limited by hardware functionality, the original UNIX operating

system had limited structuring.
 The UNIX OS consists of two separable parts
o Systems programs
o The kernel
 Consists of everything below the system-call interface and above the
physical hardware
 Provides the file system, CPU scheduling, memory management, and other
operating-system functions; a large number of functions for one level

1501352 - Operating Systems 35

Traditional UNIX System Structure
Beyond simple but not fully layered

1501352 - Operating Systems 36

 Layered Approach
 The operating system is divided into a number of
layers (levels), each built on top of lower layers.
 The bottom layer (layer 0), is the hardware; the
highest (layer N) is the user interface.
 With modularity, layers are selected such that
each uses functions (operations) and services of
only lower-level layers
 Inner layers hide details from the outer layers.
 Simplified design, easy debugging.
 Error on one layer may not affect the
other layers.
 Problems:
o 1) layer definition,
o 2) overhead per layer (changed parameters per
system call).

1501352 - Operating Systems 37

 Microkernel System Structure
 MK: to remove all non-essential services from the kernel, and implement them
as system applications instead, i.e.
o making the kernel as small and efficient as possible.

 Mach was the first example of microkernel

o Mac OS X kernel (Darwin) partly based on Mach

 Communication takes place between user modules using message passing

 Benefits:
o Easier to extend a microkernel
o Easier to port the operating system to new architectures
o More reliable (less code is running in kernel mode)
o More secure (less code is running in kernel mode)
 Detriments:
o Performance overhead of user space to kernel space communication
o Window NT -> NT 4.0 -> XP (journey again towards partial monolithism)

1501352 - Operating Systems 38

Microkernel System Structure

1501352 - Operating Systems 39

 Modules

 Most modern operating systems implement loadable kernel modules

o Uses object-oriented approach
o Each core component is separate
o Each talks to the others over known interfaces
o Each is loadable as needed within the kernel

 Overall, similar to layers but with more flexibility

o Linux, Solaris, etc

1501352 - Operating Systems 40

Solaris Modular Approach

1501352 - Operating Systems 41

 Hybrid Systems

 Most modern operating systems actually do not follow one

pure model
o Hybrid combines multiple approaches to address performance, security,
usability needs
o Linux and Solaris kernels in (single) kernel address space, so monolithic,
plus modular for dynamic loading of functionality
o Windows mostly monolithic, plus microkernel for different subsystem
(providing support for separate subsystems)

1501352 - Operating Systems 42

 Apple Mac OS X
 Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa programming
environment
o Below is kernel consisting of Mach microkernel and BSD Unix parts, plus I/O kit
and dynamically loadable modules (called kernel extensions)

1501352 - Operating Systems 43

 iOS
 Apple mobile OS for iPhone, iPad
o Structured on Mac OS X, added functionality
o Does not run OS X applications natively
o Close-sourced
 Cocoa Touch Objective-C API for developing apps
(mostly related to mobile app.)
 Media services layer for graphics, audio, video
 Core services provides cloud computing, databases
 Core OS, based on Mac OS X kernel

1501352 - Operating Systems 44

 Android
 Developed by Open Handset Alliance (mostly Google)
o Unlike iOS, it is Open Source and run on variety of
platforms
o Like iOS: layered stack
 Based on Linux kernel but modified
o Provides process, memory, device-driver management
o And adds power management
 Runtime environment includes core set of libraries and Dalvik virtual
machine
o Apps developed in Java but use Android API
Java class files compiled to Java bytecode then translated to
executable that runs on Dalvik VM

1501352 - Operating Systems 45

Android Architecture

1501352 - Operating Systems 46

 Operating-System Debugging
 Debugging is finding and fixing errors, or bugs

Kernighan’s Law: “Debugging is twice as hard as writing

the code in the first place. Therefore, if you write the code
as cleverly as possible, you are, by definition, not smart
enough to debug it.”

 OSes generate log files containing error information

1501352 - Operating Systems 47

 Operating-System Debugging
 Failure of an application can generate core dump file, capturing
memory of the process
o Usually saves the core dump to a disk file using OS file system.
 Operating system failures can generate crash dump file, containing
kernel memory
o This will not be stored in a normal file. (coz, may be the file system
fails???)
o the kernel crash dump is saved to a special unallocated portion of the disk
reserved for that purpose.

 Beyond crashes, performance tuning can optimize system performance

o Sometimes using trace listings of activities, recorded for analysis
o Profiling is periodic sampling of instruction pointer to look for statistical
trends

1501352 - Operating Systems 48

 Performance Tuning
 Improve performance by
removing bottlenecks

 OS must provide means of

computing and displaying
measures of system behavior

 For example, Windows Task

Manager, and Unix “top”
command

1501352 - Operating Systems 49

 Operating System Generation

 Operating systems are designed to run on any class of

machines; the system must be configured for each specific
computer site
 SYSGEN program
o reads from a given file, or
o asks the operator of the system for info concerning the specific
configuration of the hardware, or
o probes the hardware directly to determine what components are there.

1501352 - Operating Systems 50

 Operating System Generation

 The following kinds of information must be determined.

o What CPU is to be used?
o How will the boot disk be formatted? How many sections, or “partitions
o How much memory is available?
o What devices are available?
o What operating-system options are desired, or what parameter values
are to be used? For ex. how many buffers of which sizes, what type of
CPU-scheduling algorithm, etc.

1501352 - Operating Systems 51

 Summary

 Services provided by the OS

 User interfaces
 System Calls
o Types
o Implementation
o Parameter passing
 User mode and kernel mode operations

1501352 - Operating Systems 52

 Summary

 Operating system design and implementation

o User and system requirement
o Mechanism vs. policy
 Operating system structure
o Traditional
o Layered
o Micro kernels
o Dynamically loadable modules
o Hybrid
 OS debugging
 System generation
1501352 - Operating Systems 53
Thank You!