Lecture 2

OS Overview
The Operating System
controls the machine
gcc gdb
User OS Kernel
grep
diff
Application Hard
vi ware date
Operating System
xterm emacs
Hardware
netscape
2
A better picture

Many
applications

Application One Operating

System System
calls

Operating One Hardware

System

Hardware
3
Operating System in Action
• OS is a program, just like any other program
• When you turn power on, bootstrap program is
loaded from ROM
• Boot program
– Examine/check machine configuration
• # CPUs
• How much memory
• # and type of HW devices
– Build configuration structure describing the HW
– Locates and Loads the OS
– The control transfers to the OS
4
Operating System in Action

Operating System:
• Initialize kernel data structures
• Initialize state of HW devices
• Creates a number of processes to start
operation

5
Components of an OS
Common System Components

• Process Management
• Main Memory Management
• File Management
• I/O System Management
• Secondary Management
• Networking
• Protection System
• Command-Interpreter System
Process Management
• Creation/deletion of a process
• Create and make available, an execution environment
• Suspension/resumption and CPU scheduling in a fair manner
• Mechanisms for synchronization
• Mechanisms for inter-process communication
• Deadlock handling
Operating System Services
Operating System Services
• Program execution – system capability to load a program into
memory and to run it
• I/O operations – since user programs cannot execute I/O
operations directly, the operating system must provide some means
to perform I/O
• File-system manipulation – program capability to read, write,
create, and delete files
• Communications – exchange of information between processes
executing either on the same computer or on different systems tied
together by a network. Implemented via shared memory or
message passing
• Error detection – ensure correct computing by detecting errors in
the CPU and memory hardware, in I/O devices, or in user programs

10
System Calls
• Programming interface to the services provided by the
OS
• Typically written in a high-level language (C or C++)
• Mostly accessed by programs via a high-level
Application Program Interface (API) rather than direct
system call use
• Three most common APIs are Win32 API for Windows,
POSIX API for POSIX-based systems (including virtually
all versions of UNIX, Linux, and Mac OS X), and Java
API for the Java virtual machine (JVM)
Example of System Calls
• System call sequence to copy the contents of one file to
another file
API – System Call – OS Relationship
Dual-mode operation
• Dual-mode operation allows OS to protect itself and
other system components
– User mode and kernel mode
– 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
Transition from User to Kernel Mode
Standard C Library Example
• C program invoking printf() library call, which
calls write() system call
System Call Parameter Passing
• methods used to pass parameters to the 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 the operating system
– Block and stack methods do not limit the number or length of
parameters being passed
Types of System Calls

• Process control
• File management
• Device management
• Information maintenance
• Communications
• Protection
Examples of Windows and Unix System Calls
Operating System Design and
Implementation
OS Design and Implementation
• Design 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
• Mechanisms and policies
– Separate mechanisms from policies
– Mechanism: how to do
– Policy: what to do
• Implementation
– C, C++ (high level language)
– Porting to different architectures
Implementation
• Much variation
– Early OSes written entirely in assembly language
– Then system programming languages like Algol, PL/1
– Now C or C++ are commonly used
• Often OSes are written in a variety of languages at once…
– Lowest levels in assembly (bootloader, interrupt dispatch)
– Main body in C or C++ (possibly a limited subset of C++)
– Systems programs in C, C++, scripting languages like Perl
or Python, shell scripts
• More high-level language easier to port to other hardware
– But slower
• However, ease of development/maintenance makes it
worth using a higher-level language
• Emulation can allow an OS to run on non-native hardware
OS Structures
• Simple Structure (MSDOS)

• Layered Approach (UNIX)

• Monolithic + Modules Approach(Linux, Windows

9x)

• Microkernel Approach (Mach)

• Hybrid (Windows NT, XNU/OS X)

Simple Structure
• MS-DOS – written to provide
the most functionality in the
least space
– Not divided into modules
– Although MS-DOS has
some structure, its
interfaces and levels of
functionality are not well
separated
Example: MS-DOS
• Single-tasking
• Shell invoked when
system booted
• Simple method to run
program
– No process created
• Single memory space
• Loads program into
memory, overwriting
all but the kernel
• Program exit -> shell At system startup running a program
reloaded
 Layered Approach
• OS divided into number of layers
- bottom layer is hardware,
highest layer is the user
interface.

• Each layer uses functions and

services of only lowerlevel layers

• THE Operating System and

Linux Kernel has successive
layers of abstraction.
Unix OS architecture

System programs
and
System libraries
(one layer)

Kernel
(another layer)

27 From https://www.tutorialspoint.com
Monolithic vs. Microckernel
Design
• MS-DOS, UNIX, and most other OSes implement what is called a monolithic
design
– Kernel is relatively large, contains much code
– File systems, device drivers, etc. are all run with full kernel privileges
– Hybrid/Layered systems are still largely monolithic designs!
• MINIX and Mach are examples of a Microkernel design
– Kernel is small, delegates much of core system functionality to user-
space daemons
– Typically only the most core functionality is implemented in kernel space
• Process and memory management, message passing
– Benefits include that it is easier to extend/port a microkernel, more
reliable/secure (less code is running in kernel mode)
– Detriments include performance overhead of user space to kernel space
communication
Monolithic vs. Microckernel
Design
• Monolithic OSes have large kernels with a lot of components
• Linux, Windows, Mac
• Microkernels moves as much from the kernel into “user” space
Small core OS components running at kernel level
OS Services built from many independent user-level processes
Communication between modules with message passing
• Benefits:
Easier to extend a microkernel
Easier to port OS to new architectures
More reliable and more secure (less code is running in kernel mode) Fault
Isolation (parts of kernel protected from other par

• Detriments: • Performance overhead severe for naïve implementation

Monolithic vs. Microckernel
Design
Modules
• Most modern operating systems implement kernel modules
– Uses object-oriented approach
– Each core component is separate
– Each talks to the others over known interfaces
– Each is loadable as needed within the kernel
• Overall, similar to layers but more flexible
User mode App App

module
• Linux supports modules Monolithic module
Kernel mode kernel module

module module module

31
Hybrid Systems

• Mac OS X
– Uses Mach and BSD kernels
– Mach: microkernel
– BSD: monolithic

32