 An operating system is a program that manages a

computer’s hardware.
 It also provides a basis for application programs
 IT acts as an intermediary between the computer
user and the computer hardware.
 Operating system goals:
 Execute user programs and make solving user problems
easier
 Make the computer system convenient to use
 Use the computer hardware in an efficient manner
 Computersystem can be divided into four
components:
 Hardware – provides basic computing resources
 CPU, memory, I/O devices
 Operating system
 Controls and coordinates use of hardware among various
applications and users
 Application programs – define the ways in which the
system resources are used to solve the computing
problems of the users
 Word processors, compilers, web browsers, database systems,
video games
 Users
 People, machines, other computers
 The operating system will control the hardware
and coordinates its use among the various
application programs for various users.
 Computer system: CPU, Memory, Software and
Data
 The operating system provides the means for
proper use of these resources in the operation
of the computer system.
 Operating system can be viewed from two
viewpoints:
 The user
 The System
 Single User Computer (PC, Work Station) Such a system is designed for one user to
monopolize its resources. The goal is to maximize the work (or play) that the user is
performing. In this case, the operating system is designed mostly for ease of use, with some
attention paid to performance and none paid to resource utilization—how various
hardware and software resources are shared.
 Multi User Computer (e.g. mainframes) users share resources and may exchange
information. The operating system in such cases is designed to maximize resource
utilization— to assure that all available CPU time, memory, and I/O are used efficiently
and that no individual user takes more than her fair share. In other cases, users sit at
workstations connected to networks of other workstations and servers. These users have
dedicated resources at their disposal, but they also share resources such as networking and
servers, including file, compute, and print servers. Therefore, their operating system is
designed to compromise between individual usability and resource utilization.
 Handheld Computers (Mobile Phones) Most mobile computers are standalone units for
individual users. Quite often, they are connected to networks through cellular or other
wireless technologies. Increasingly, these mobile devices are replacing desktop and laptop
computers for people who are primarily interested in using computers for e-mail and web
browsing. The user interface for mobile computers generally features a touch screen, where
the user interacts with the system by pressing and swiping fingers across the screen rather
than using a physical keyboard and mouse.
 Embedded computers home devices and automobiles may have numeric keypads and
may turn indicator lights on or off to show status, but they and their operating systems are
designed primarily to run without user intervention.
 From the computer’s point of view, the operating system is the program
most intimately involved with the hardware. In this context, we can
view an operating system as a resource allocator.
 A computer system has many resources that may be required to solve a
problem: CPU time, memory space, file-storage space, I/O devices,
and so on. The operating system acts as the manager of these resources.
 Facing numerous and possibly conflicting requests for resources, the
operating system must decide how to allocate them to specific
programs and users so that it can operate the computer system
efficiently and fairly. As we have seen, resource allocation is especially
important where many users access the same mainframe or
minicomputer.
 A slightly different view of an operating system emphasizes the need to
control the various I/O devices and user programs. An operating
system is a control program. A control program manages the
execution of user programs to prevent errors and improper use of the
computer. It is especially concerned with the operation and control of
I/O devices.
 Operating systems exist because they offer a reasonable way to solve the problem
of creating a usable computing system.
 Fundamental goal of a computer is to execute user programs and to make solving
user problems easier.
 Since bare hardware alone is not particularly easy to use, application programs are
developed.
 These programs require certain common operations, such as those controlling the
I/O devices. The common functions of controlling and allocating resources are then
brought together into one piece of software: the operating system.
 A more common definition, and the one that we usually follow, is that the operating
system is the one program running at all times on the computer—usually
called the kernel.
 Along with the kernel, there are two other types of programs: system programs,
which are associated with the operating system but are not necessarily part of the
kernel, and application programs, which include all programs not associated with
the operation of the system.
 In mobile devices, we see that once again the number of features constituting the
operating system is increasing. Mobile operating systems often include not only a
core kernel but also middleware—a set of software frameworks that provide
additional services to application developers. For example, each of the two most
prominent mobile operating systems—Apple’s iOS and Google’s Android—features
a core kernel along with middleware that supports databases, multimedia, and
graphics (to name a only few).
 A modern general-purpose computer system consists of one or more CPUs and a
number of device controllers connected through a common bus that provides
access to shared memory (see Figure). Each device controller is in charge of a
specific type of device (for example, disk drives, audio devices, or video
displays). The CPU and the device controllers can execute in parallel, competing
for memory cycles. To ensure orderly access to the shared memory, a memory
controller synchronizes access to the memory.
 For a computer to start running—for instance, when it is powered up or rebooted—
it needs to have an initial program to run. This initial program, or bootstrap
program, tends to be simple. Typically, it is stored within the computer hardware in
read-only memory (ROM) or electrically erasable programmable read-only
memory (EEPROM), known by the general term firmware.
 It initializes all aspects of the
system, from CPU registers to
device controllers to memory
contents. The bootstrap program
must know how to load the
operating system and how to start
executing that system.
 To accomplish this goal, the
bootstrap program must locate
the operating-system kernel and
load it into memory.
 Once the kernel is loaded and executing, it can start providing services to the system and
its users. Some services are provided outside of the kernel, by system programs that are
loaded into memory at boot time to become system processes, or system daemons that run
the entire time the kernel is running.
 On UNIX, the first system process is “init,” and it starts many other daemons. Once this phase is
complete, the system is fully booted, and the system waits for some event to occur.
 The occurrence of an event is usually signaled by an interrupt from either the hardware or
the software. Hardware may trigger an interrupt at any time by sending a signal to the CPU,
usually by way of the system bus. Software may trigger an interrupt by executing a special
operation called a system call (also called a monitor call). Software generated interrupts are
often called trap or exception.
 When the CPU is interrupted, it stops what it is doing and immediately transfers execution
to a fixed location. The fixed location usually contains the starting address where the
service routine for the interrupt is located. The interrupt service routine executes; on
completion, the CPU resumes the interrupted computation. A timeline of this operation is shown
in Figure.
 Interrupts are an important part of a computer architecture. Each computer design has its own
interrupt mechanism, but several functions are common.
 The interrupt must transfer control to the appropriate interrupt service routine. The
straightforward method for handling this transfer would be to invoke a generic routine to
examine the interrupt information. The routine, in turn, would call the interrupt-specific
handler.
 However, interrupts must be handled quickly. Since only a predefined number of interrupts
is possible, a table of pointers to interrupt routines can be used instead to provide the
necessary speed.
 The interrupt routine is called indirectly through the table, with no intermediate routine
needed. Generally, the table of pointers is stored in low memory (the first hundred or so
locations). These locations hold the addresses of the interrupt service routines for the
various devices. This array, or interrupt vector, of addresses is then indexed by a unique device
number, given with the interrupt request, to provide the address of the interrupt service routine
for the interrupting device.
 Operating systems as different as Windows and UNIX dispatch interrupts in this manner.

 The interrupt architecture must also save the address of the interrupted instruction. Many old
designs simply stored the interrupt address in a fixed location or in a location indexed by the
device number. More recent architectures store the return address on the system stack. If the
interrupt routine needs to modify the processor state—for instance, by modifying register
values—it must explicitly save the current state and then restore that state before returning.
After the interrupt is serviced, the saved return address is loaded into the program counter, and
the interrupted computation resumes as though the interrupt had not occurred.
 I/O devices and the CPU can execute
concurrently
 Each device controller is in charge of a
particular device type
 Each device controller has a local
buffer
 CPU moves data from/to main memory
to/from local buffers
 I/O is from the device to local buffer of
controller

 Device controller informs CPU that it has finished its operation by causing an
interrupt
 The operating system preserves the state of the CPU by storing registers and
the program counter
 Determines which type of interrupt has occurred:
 polling
 vectored interrupt system

 Separate segments of code determine what action should be taken for each type
of interrupt
 A general-purpose computer system consists of CPUs and multiple device controllers that
are connected through a common bus.
 Each device controller is in charge of a specific type of device. Depending on the
controller, more than one device may be attached. For instance, seven or more devices can
be attached to the small computer-systems interface (SCSI) controller.
 A device controller maintains some local buffer storage and a set of special-purpose
registers. The device controller is responsible for moving the data between the peripheral
devices that it controls and its local buffer storage.
 Typically, operating systems have a device driver for each device controller. This device
driver understands the device controller and provides the rest of the operating system with
a uniform interface to the device.
 To start an I/O operation, the device driver loads the appropriate register within the device
controller
 After I/O starts, control returns to user program only upon I/O completion
 Wait instruction idles the CPU until the next interrupt
 Wait loop (contention for memory access)
 At most one I/O request is outstanding at a time, no simultaneous I/O processing

 After I/O starts, control returns to user program without waiting for I/O completion
 System call – request to the OS to allow user to wait for I/O completion
 Device-status table contains entry for each I/O device indicating its type, address, and state
 OS indexes into I/O device table to determine device status and to modify table entry to include
interrupt
 To start an I/O operation, the device driver loads the appropriate registers within
the device controller. The device controller, in turn, examines the contents of
these registers to determine what action to take (such as “read a character from
the keyboard”).
 The controller starts the transfer of data from the device to its local buffer. Once
the transfer of data is complete, the device controller informs the device driver
via an interrupt that it has finished its operation.
 The device driver then returns control to the operating system, possibly returning
the data or a pointer to the data if the operation was a read.
 For other operations, the device driver returns status information.

 This form of interrupt-driven I/O is fine for moving small amounts of data but can
produce high overhead when used for bulk data movement such as disk I/O.
 To solve this problem, direct memory access (DMA) is used. After setting up
buffers, pointers, and counters for the I/O device, the device controller transfers
an entire block of data directly to or from its own buffer storage to memory, with
no intervention by the CPU. Only one interrupt is generated per block, to tell the
device driver that the operation has completed, rather than the one interrupt per
byte generated for low-speed devices.
 While the device controller is performing these operations, the CPU is available
to accomplish other work.
The basic unit of computer storage is the bit. A bit can contain one of two values, 0 and
1. All other storage in a computer is based on collections of bits. Given enough bits, it is
amazing how many things a computer can represent: numbers, letters, images, movies,
sounds, documents, and programs, to name a few. A byte is 8 bits, and on most
computers it is the smallest convenient chunk of storage. For example, most computers
don’t have an instruction to move a bit but do have one to move a byte. A less common
term is word, which is a given computer architecture’s native unit of data. A word is
made up of one or more bytes. For example, a computer that has 64-bit registers and
64-bit memory addressing typically has 64-bit (8-byte) words. A computer executes
many operations in its native word size rather than a byte at a time.

Computer storage, along with most computer throughput, is generally measured and
manipulated in bytes and collections of bytes.
A kilobyte, or KB, is 1,024 bytes
a megabyte, or MB, is 1,0242 bytes
a gigabyte, or GB, is 1,0243 bytes
a terabyte, or TB, is 1,0244 bytes
a petabyte, or PB, is 1,0245 bytes

Computer manufacturers often round off these numbers and say that a megabyte is 1
million bytes and a gigabyte is 1 billion bytes. Networking measurements are an
exception to this general rule; they are given in bits (because networks move data a bit
at a time).
 Main memory – only large storage media that the CPU
can access directly
 Random access
 Typically volatile

 Secondary storage – extension of main memory that

provides large nonvolatile storage capacity
 Hard disks – rigid metal or glass platters covered with
magnetic recording material
 Disk surface is logically divided into tracks, which are subdivided
into sectors
 The disk controller determines the logical interaction between the
device and the computer

 Solid-state disks – faster than hard disks, nonvolatile

 Various technologies
 Becoming more popular

 Tertiary storage
 Storage systems organized in hierarchy
 Speed
 Cost
 Volatility

 Caching –
 copying information into faster storage system;
 main memory can be viewed as a cache for
secondary storage
 Device Driver for each device controller to
manage I/O
 Provides uniform interface between controller and
kernel
 Important principle, performed at many levels in a computer (in
hardware, operating system, software)
 Information in use copied from slower to faster storage temporarily
 Faster storage (cache) checked first to determine if information is there
 If it is, information used directly from the cache (fast)
 If not, data copied to cache and used there

 Cache smaller than storage being cached

 Cache management important design problem
 Cache size and replacement policy
A von Neumann architecture
 Most systems use a single general-purpose processor
 Most systems have special-purpose processors as well

 Multiprocessors systems growing in use and importance

 Also known as parallel systems, tightly-coupled systems
 Advantages include:
1. Increased throughput
2. Economy of scale
3. Increased reliability – graceful degradation or fault tolerance
 Two types:
1. Asymmetric Multiprocessing – each processor is assigned a specie
task.
2. Symmetric Multiprocessing – each processor performs all tasks
 Multi-chip and multicore

 Systems containing all chips

 Chassis containing multiple separate systems
 Like multiprocessor systems, but multiple systems working together
 Usually sharing storage via a storage-area network (SAN)
 Provides a high-availability service which survives failures
 Asymmetric clustering has one machine in hot-standby mode
 Symmetric clustering has multiple nodes running applications, monitoring each
other
 Some clusters are for high-performance computing (HPC)
 Applications must be written to use parallelization
 Some have distributed lock manager (DLM) to avoid conflicting
operations
 Multiprogramming (Batch system) needed for efficiency
 Single user cannot keep CPU and I/O devices busy at all times
 Multiprogramming organizes jobs (code and data) so CPU always has one to
execute
 A subset of total jobs in system is kept in memory
 One job selected and run via job scheduling
 When it has to wait (for I/O for example), OS switches to another job

 Timesharing (multitasking) is logical extension in which CPU switches

jobs so frequently that users can interact with each job while it is running,
creating interactive computing
 Response time should be < 1 second
 Each user has at least one program executing in memory process
 If several jobs ready to run at the same time  CPU scheduling
 If processes don’t fit in memory, swapping moves them in and out to run
 Virtual memory allows execution of processes not completely in memory
 Interrupt driven (hardware and software)
 Hardware interrupt by one of the devices
 Software interrupt (exception or trap):
 Software error (e.g., division by zero)
 Request for operating system service
 Other process problems include infinite loop, processes modifying each
other or the operating system
 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

 Increasingly CPUs support multi-mode operations

 i.e. virtual machine manager (VMM) mode for guest VMs
 Timer to prevent infinite loop / process hogging resources
 Timer is set to interrupt the computer after some time period
 Keep a counter that is decremented by the physical clock.
 Operating system set the counter (privileged instruction)
 When counter zero generate an interrupt
 Set up before scheduling process to regain control or terminate
program that exceeds allotted time
 A process is a program in execution. It is a unit of work within the
system. Program is a passive entity, process is an active entity.
 Process needs resources to accomplish its task
 CPU, memory, I/O, files
 Initialization data

 Process termination requires reclaim of any reusable resources

 Single-threaded process has one program counter specifying
location of next instruction to execute
 Process executes instructions sequentially, one at a time, until
completion
 Multi-threaded process has one program counter per thread
 Typically system has many processes, some user, some operating
system running concurrently on one or more CPUs
 Concurrency by multiplexing the CPUs among the processes / threads
The operating system is responsible for the following activities in
connection with process management:

 Creating and deleting both user and system processes

 Suspending and resuming processes
 Providing mechanisms for process synchronization
 Providing mechanisms for process communication
 Providing mechanisms for deadlock handling
 To execute a program all (or part) of the instructions must be in
memory
 All (or part) of the data that is needed by the program must be in
memory.
 Memory management determines what is in memory and when
 Optimizing CPU utilization and computer response to users

 Memory management activities

 Keeping track of which parts of memory are currently being used and by
whom
 Deciding which processes (or parts thereof) and data to move into and out of
memory
 Allocating and deallocating memory space as needed
 OS provides uniform, logical view of information storage
 Abstracts physical properties to logical storage unit - file
 Each medium is controlled by device (i.e., disk drive, tape drive)
 Varying properties include access speed, capacity, data-transfer rate,
access method (sequential or random)

 File-System management
 Files usually organized into directories
 Access control on most systems to determine who can access what
 OS activities include
 Creating and deleting files and directories
 Primitives to manipulate files and directories
 Mapping files onto secondary storage
 Backup files onto stable (non-volatile) storage media
 Usually disks used to store data that does not fit in main memory or
data that must be kept for a “long” period of time
 Proper management is of central importance
 Entire speed of computer operation hinges on disk subsystem and
its algorithms
 OS activities
 Free-space management
 Storage allocation
 Disk scheduling

 Some storage need not be fast

 Tertiary storage includes optical storage, magnetic tape
 Still must be managed – by OS or applications
 Varies between WORM (write-once, read-many-times) and RW (read-
write)
Movement between levels of storage hierarchy can be explicit
or implicit
 Multitasking environments must be careful to use most recent value,
no matter where it is stored in the storage hierarchy

 Multiprocessor environment must provide cache coherency in

hardware such that all CPUs have the most recent value in their cache
 Distributed environment situation even more complex
 Several copies of a datum can exist
 Various solutions covered in Chapter 17
 One purpose of OS is to hide peculiarities of hardware devices from
the user
 I/O subsystem responsible for
 Memory management of I/O including buffering (storing data
temporarily while it is being transferred), caching (storing parts of data in
faster storage for performance), spooling (the overlapping of output of
one job with input of other jobs)
 General device-driver interface
 Drivers for specific hardware devices
 Protection – any mechanism for controlling access of processes
or users to resources defined by the OS
 Security – defense of the system against internal and external
attacks
 Huge range, including denial-of-service, worms, viruses, identity theft,
theft of service
 Systems generally first distinguish among users, to determine
who can do what
 User identities (user IDs, security IDs) include name and associated
number, one per user
 User ID then associated with all files, processes of that user to
determine access control
 Group identifier (group ID) allows set of users to be defined and
controls managed, then also associated with each process, file
 Privilege escalation allows user to change to effective ID with more
rights
n Many similar to standard programming data structures
n Singly linked list

n Doubly linked list

n Circular linked list

 Binary search tree
left <= right
 Search performance is O(n)
 Balanced binary search tree is O(lg n)
 Hash function can create a hash map

 Bitmap – string of n binary digits representing the status of n items

 Linux data structures defined in

include files <linux/list.h>, <linux/kfifo.h>,

<linux/rbtree.h>
 Stand-alone general purpose machines
 But blurred as most systems interconnect with others (i.e., the
Internet)
 Portals provide web access to internal systems
 Network computers (thin clients) are like Web terminals
 Mobile computers interconnect via wireless networks
 Networking becoming ubiquitous – even home systems use firewalls
to protect home computers from Internet attacks
 Handheld smartphones, tablets, etc
 What is the functional difference between them and a “traditional”
laptop?
 Extra feature – more OS features (GPS, gyroscope)
 Allows new types of apps like augmented reality
 Use IEEE 802.11 wireless, or cellular data networks for connectivity
 Leaders are Apple iOS and Google Android
 Distributed computing
 Collection of separate, possibly heterogeneous, systems networked together
 Network is a communications path, TCP/IP most common
 Local Area Network (LAN)
 Wide Area Network (WAN)
 Metropolitan Area Network (MAN)
 Personal Area Network (PAN)
 Network Operating System provides features between systems across network
 Communication scheme allows systems to exchange messages
 Illusion of a single system
 Client-Server Computing
 Dumb terminals supplanted by smart PCs
 Many systems now servers, responding to requests generated
by clients
 Compute-server system provides an interface to client to
request services (i.e., database)
 File-server system provides interface for clients to store
and retrieve files
 Another model of distributed system
 P2P does not distinguish clients and servers
 Instead all nodes are considered peers
 May each act as client, server or both
 Node must join P2P network
 Registers its service with central lookup service
on network, or
 Broadcast request for service and respond to
requests for service via discovery protocol
 Examples include Napster and Gnutella, Voice
over IP (VoIP) such as Skype
 Allows operating systems to run applications within other OSes
 Vast and growing industry

 Emulation used when source CPU type different from target type
(i.e. PowerPC to Intel x86)
 Generally slowest method
 When computer language not compiled to native code – Interpretation

 Virtualization – OS natively compiled for CPU, running guest OSes

also natively compiled
 Consider VMware running WinXP guests, each running applications, all
on native WinXP host OS
 VMM (virtual machine Manager) provides virtualization services
 Use cases involve laptops and desktops running multiple
OSes for exploration or compatibility
 Apple laptop running Mac OS X host, Windows as a guest
 Developing apps for multiple OSes without having multiple
systems
 QA testing applications without having multiple systems
 Executing and managing compute environments within data
centers
 VMM can run natively, in which case they are also the
host
 There is no general purpose host then (VMware ESX and
Citrix XenServer)
 Delivers computing, storage, even apps as a service across a network

 Logical extension of virtualization because it uses virtualization as the base for

it functionality.
 Amazon EC2 has thousands of servers, millions of virtual machines,
petabytes of storage available across the Internet, pay based on usage
 Many types
 Public cloud – available via Internet to anyone willing to pay
 Private cloud – run by a company for the company’s own use
 Hybrid cloud – includes both public and private cloud components
 Software as a Service (SaaS) – one or more applications available via the
Internet (i.e., word processor)
 Platform as a Service (PaaS) – software stack ready for application use via the
Internet (i.e., a database server)
 Infrastructure as a Service (IaaS) – servers or storage available over Internet
(i.e., storage available for backup use)
 Cloud computing environments composed of traditional OSes, plus
VMMs, plus cloud management tools
 Internet connectivity requires security like firewalls
 Load balancers spread traffic across multiple applications
 Real-time embedded systems most prevalent form of computers
 Vary considerable, special purpose, limited purpose OS, real-time OS
 Use expanding

 Many other special computing environments as well

 Some have OSes, some perform tasks without an OS

 Real-time OS has well-defined fixed time constraints

 Processing must be done within constraint
 Correct operation only if constraints met
 Operating systems made available in source-code format rather than just
binary closed-source
 Counter to the copy protection and Digital Rights Management
(DRM) movement
 Started by Free Software Foundation (FSF), which has “copyleft” GNU
Public License (GPL)
 Examples include GNU/Linux and BSD UNIX (including core of Mac
OS X), and many more
 Can use VMM like VMware Player (Free on Windows), Virtualbox (open
source and free on many platforms - http://www.virtualbox.com)
 Use to run guest operating systems for exploration
 Identify services provided by an operating system
 Illustrate how system calls are used to provide
operating system services
 Compare and contrast monolithic, layered,
microkernel, modular, and hybrid strategies for
designing operating systems
 Illustrate the process for booting an operating system
 Apply tools for monitoring operating system
performance
 Design and implement kernel modules for interacting
with a Linux kernel
 Operating systems provide an environment for execution of
programs and services to programs and users
 One set of operating-system services provides functions that are
helpful to the user:
 User interface - Almost all operating systems have a user interface (UI).
 Command-Line (CLI), uses text commands and a method for entering them (say, a keyboard for
typing in commands in a specific format with specific options)
 Batch Interface commands and directives to control those commands are entered into files, and
those files are executed.

 Graphics User Interface (GUI), the interface is a window system with a pointing device to direct I/O,
choose from menus, and make selections and a keyboard to enter text.
 touch-screen,
 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)
 I/O operations - A running program may require I/O, which may involve
a file or an I/O device. For security User don have direct control over I/O
rather
 File-system manipulation - The file system is of particular interest.
Programs need to read and write files and directories, create and delete
them, search them, list file Information, permission management.
 One set of operating-system services provides
functions that are helpful to the user (Cont.):
 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)
 Error detection – OS needs to be constantly aware of
possible errors
 May occur in the 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
 Another set of OS functions exists for ensuring the efficient
operation of the system itself via resource sharing
 Resource allocation - When multiple users or multiple jobs
running concurrently, resources must be allocated to each of them
 Many types of resources - CPU cycles, main memory, file storage, I/O
devices.
 Accounting - To keep track of which users use how much and what
kinds of computer resources. Usage Statistics.
 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
 Command Line interpreter
 CLI 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
 If the latter, adding new features doesn’t require shell modification
 Bourne Shell, C Shell, Bourne Again Shell, Korn Shell.
 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 interfaces

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

 Voice commands
 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
Programming 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)

Note that the system-call names used throughout this text are
generic
 Writing a simple program to read data from one file and copy them to
another file.
 The first input that the program will need is the names of the two files: the
input file and the output file.
 These names can be specified in many ways, depending on the operating-
system design. One approach is for the program to ask the user for the names.
In an interactive system, this approach will require a sequence of system
calls, first to write a prompting message on the screen and then to read
from the keyboard the characters that define the two files.
 On mouse-based and icon-based systems, a menu of file names is usually
displayed in a window. The user can then use the mouse to select the source
name, and a window can be opened for the destination name to be specified.
This sequence requires many I/O system calls.
 Once the two file names have been obtained, the program must open the input
file and create the output file. Each of these operations requires another
system call.
 Possible error conditions for each operation can require additional system
calls. When the program tries to open the input file, for example, it may find
that there is no file of that name or that the file is protected against access. In
these cases, the program should print a message on the console (another
sequence of system calls) and then terminate abnormally (another system
call).
 Writing a simple program to read data from one file and copy them to
another file.
 If the input file exists, then we must create a new output file. We may find that
there is already an output file with the same name. This situation may cause the
program to abort (a system call), or we may delete the existing file (another
system call) and create a new one (yet another system call).
 Another option, in an interactive system, is to ask the user (via a sequence of
system calls to output the prompting message and to read the response from
the terminal) whether to replace the existing file or to abort the program.
When both files are set up, we enter a loop that reads from the input file (a
system call) and writes to the output file (another system call). Each read and
write must return status information regarding various possible error
conditions. On input, the program may find that the end of the file has been
reached or that there was a hardware failure in the read (such as a parity
error).
 The write operation may encounter various errors, depending on the output
device (for example, no more disk space).
 Finally, after the entire file is copied, the program may close both files
(another system call), write a message to the console or window (more system
calls), and finally terminate normally (the final system call). This system-call
sequence is shown in Figure 2.5.
 System call sequence to copy the contents of one file to
another file
 Typically, a number is associated with each system call
 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 need know nothing about how the system call is
implemented
 Just needs 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)
 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 general 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
 Process control
 create process, terminate process
 end, abort
 load, execute
 get process attributes, set process attributes
 wait for time
 wait event, signal event
 allocate and free memory
 Dump memory if error
 Debugger for determining bugs, single step execution
 Locks for managing access to shared data between processes
 File management
 create file, delete file
 open, close file
 read, write, reposition
 get and set file attributes

 Device management
 request device, release device
 read, write, reposition
 get device attributes, set device attributes
 logically attach or detach devices
 Information maintenance
 get time or date, set time or date
 get system data, set system data
 get and set process, file, or device attributes

 Communications
 create, delete communication connection
 send, receive messages if message passing model to host name or
process name
 From client to server
 Shared-memory model create and gain access to memory regions
 transfer status information
 attach and detach remote devices
 Protection
 Control access to resources
 Get and set permissions
 Allow and deny user access
 C program invoking printf() library call, which calls write()
system call
 Single-tasking
 No operating system
 Programs (sketch) loaded
via USB into flash memory
 Single memory space
 Boot loader loads program
 Program exit -> shell
reloaded
At system startup running a program
 Unix variant
 Multitasking
 User login -> invoke user’s choice of
shell
 Shell executes fork() system call to
create process
 Executes exec() to load program into
process
 Shell waits for process to terminate or
continues with user commands
 Process exits with:
 code = 0 – no error
 code > 0 – error code
 System programs provide a convenient environment for
program development and execution. They can be divided
into:
 File manipulation
 Status information sometimes stored in a file
 Programming language support
 Program loading and execution
 Communications
 Background services
 Application programs

 Most users’ view of the operating system is defined by system

programs, not the actual system calls
 Provide a convenient environment for program
development and execution
 Some of them are simply user interfaces to system calls; others
are considerably more complex

 File management - Create, delete, copy, rename, print,

dump, list, and generally manipulate files and directories

 Status information
 Some ask the system for info - date, time, amount of available
memory, disk space, number of users
 Others provide detailed performance, logging, and debugging
information
 Typically, these programs format and print the output to the
terminal or other output devices
 Some systems implement a registry - used to store and retrieve
configuration information
 File modification
 Text editors to create and modify files
 Special commands to search contents of files or perform
transformations of the text
 Programming-language support - Compilers, assemblers,
debuggers and interpreters sometimes provided
 Program loading and execution- Absolute loaders,
relocatable loaders, linkage editors, and overlay-loaders,
debugging systems for higher-level and machine language
 Communications - Provide the mechanism for creating
virtual connections among processes, users, and computer
systems
 Allow users to send messages to one another’s screens, browse
web pages, send electronic-mail messages, log in remotely,
transfer files from one machine to another
 Background Services
 Launch at boot time
 Some for system startup, then terminate
 Some from system boot to shutdown
 Provide facilities like disk checking, process scheduling, error
logging, printing
 Run in user context not kernel context
 Known as services, subsystems, daemons

 Application programs
 Don’t pertain to system
 Run by users
 Not typically considered part of OS
 Launched by command line, mouse click, finger poke
 Source code compiled into object files designed to be loaded into any physical memory
location – relocatable object file
 Linker combines these into single binary executable file
 Also brings in libraries

 Program resides on secondary storage as binary executable

 Must be brought into memory by loader to be executed
 Relocation assigns final addresses to program parts and adjusts code and data in program to match
those addresses
 Modern general purpose systems don’t link libraries into executables
 Rather, dynamically linked libraries (in Windows, DLLs) are loaded as needed, shared by all that use
the same version of that same library (loaded once)
 Object, executable files have standard formats, so operating system knows how to load
and start them
 Apps compiled on one system usually not executable on other
operating systems
 Each operating system provides its own unique system calls
 Own file formats, etc.

 Apps can be multi-operating system

 Written in interpreted language like Python, Ruby, and interpreter
available on multiple operating systems
 App written in language that includes a VM containing the running
app (like Java)
 Use standard language (like C), compile separately on each
operating system to run on each
 Application Binary Interface (ABI) is architecture equivalent of
API, defines how different components of binary code can
interface for a given operating system on a given architecture,
CPU, etc.
 Design and Implementation of OS is not “solvable”, but
some approaches have proven successful
 Internal structure of different Operating Systems can vary
widely
 Start the design by defining goals and specifications
 Affected by choice of hardware, type of system
 User goals and System goals
 User goals – operating system should be convenient to use, easy
to learn, reliable, safe, and fast
 System goals – operating system should be easy to design,
implement, and maintain, as well as flexible, reliable, error-free,
and efficient
 Specifying and designing an OS is highly creative task of
software engineering
 Policy: What needs to be done?
 Example: Interrupt after every 100 seconds

 Mechanism: How to do something?

 Example: timer

 Important principle: separate policy from mechanism

 The separation of policy from mechanism is a very
important principle, it allows maximum flexibility if policy
decisions are to be changed later.
 Example: change 100 to 200
 Much variation
 Early OSes in assembly language
 Then system programming languages like Algol, PL/1
 Now C, C++

 Actually usually a mix of languages

 Lowest levels in assembly
 Main body in C
 Systems programs in C, C++, scripting languages like PERL,
Python, shell scripts
 More high-level language easier to port to other hardware
 But slower

 Emulation can allow an OS to run on non-native hardware

 General-purpose OS is very large program
 Various ways to structure ones
 Simple structure – MS-DOS
 More complex – UNIX
 Layered – an abstraction
 Microkernel – Mach
 MS-DOS
 Many operating systems do not have well-
defined structures. Frequently, such systems
started as small, simple, and limited systems
and then grew beyond their original scope.
 MS-DOS is an example of such a system. It
was originally designed and implemented by
a few people who had no idea that it would
become so popular.
 It was written to provide the most functionality
in the least space, so it was not carefully
divided into modules. Figure shows its
structure.
 In MS-DOS, the interfaces and levels of
functionality are notwell separated. For
instance, application programs are able to
access the basic I/O routines to write directly
to the display and disk drives. Such freedom
leaves MS-DOS vulnerable to errant (or
malicious) programs, causing entire system
 UNIX – limited by hardware functionality, the original UNIX operating
system had limited structuring.
 The UNIX OS consists of two separable parts
 Systems programs
 The kernel (divided into series of device drivers and interfaces)
 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
Monolithic plus modular design
 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
 The operating system can then retain
much greater control over the
computer and over the applications that
make use of that computer.
 The main advantage of the layered
approach is simplicity of construction
and debugging. The layers are selected
so that each uses functions (operations)
and services of only lower-level layers.
 This approach simplifies debugging
and system verification. The first layer
can be debugged without any concern
for the rest of the system, because, by
definition, it uses only the basic
hardware (which is assumed correct) to
implement its functions.
 Once the first layer is debugged, its
correct functioning can be assumed
while the second layer is debugged,
and so on. If an error is found during
the debugging of a particular layer, the
error must be on that layer, because the
layers below it are already debugged.
 Thus, the design and implementation of the system are simplified.
 Each layer is implemented only with operations provided by lower-level
layers. A layer does not need to know how these operations are
implemented; it needs to know only what these operations do. Hence,
each layer hides the existence of certain data structures, operations, and
hardware from higher-level layers.
 Moves as much from the kernel into user space
 This method structures the operating system by removing all
nonessential components from the kernel and implementing them
as system and user-level programs. The result is a smaller kernel.
 Mach is an example of microkernel
 Mac OS X kernel (Darwin) partly based on Mach

 Communication takes place between user modules using message

passing
 Benefits:
 Easier to extend a microkernel
 Easier to port the operating system to new architectures
 More reliable (less code is running in kernel mode)
 More secure

 Detriments:
 Performance overhead of user space to kernel space communication
 Many modern operating systems implement loadable kernel
modules (LKMs)
 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 with more flexible

 Linux, Solaris, etc.
 Most modern operating systems are not one pure model
 Hybrid combines multiple approaches to address performance,
security, usability needs
 Linux and Solaris kernels in kernel address space, so monolithic,
plus modular for dynamic loading of functionality
 Windows mostly monolithic, plus microkernel for different
subsystem personalities
 Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa
programming environment
 Below is kernel consisting of Mach microkernel and BSD Unix
parts, plus I/O kit and dynamically loadable modules (called kernel
extensions)
 Developed by Open Handset Alliance (mostly Google)
 Open Source

 Similar stack to iOS

 Based on Linux kernel but modified
 Provides process, memory, device-driver management
 Adds power management

 Runtime environment includes core set of libraries and

Dalvik virtual machine
 Apps developed in Java plus Android API
 Java class files compiled to Java bytecode then translated to
executable thnn runs in Dalvik VM

 Libraries include frameworks for web browser (webkit),

database (SQLite), multimedia, smaller libc
 Operating systems generally designed to run on a class of
systems with variety of peripherals
 Commonly, operating system already installed on purchased
computer
 But can build and install some other operating systems
 If generating an operating system from scratch
 Write the operating system source code
 Configure the operating system for the system on which it will run
 Compile the operating system
 Install the operating system
 Boot the computer and its new operating system
 Download Linux source code (http://www.kernel.org)
 Configure kernel via “make menuconfig”
 Compile the kernel using “make”
 Produces vmlinuz, the kernel image
 Compile kernel modules via “make modules”
 Install kernel modules into vmlinuz via “make
modules_install”
 Install new kernel on the system via “make install”
 When power initialized on system, execution starts at a fixed
memory location
 Operating system must be made available to hardware so
hardware can start it
 Small piece of code – bootstrap loader, BIOS, stored in ROM or EEPROM
locates the kernel, loads it into memory, and starts it
 Sometimes two-step process where boot block at fixed location
loaded by ROM code, which loads bootstrap loader from disk
 Modern systems replace BIOS with Unified Extensible Firmware
Interface (UEFI)
 Common bootstrap loader, GRUB, allows selection of kernel
from multiple disks, versions, kernel options
 Kernel loads and system is then running
 Boot loaders frequently allow various boot states, such as
single user mode
 Debugging is finding and fixing errors, or bugs
 Also performance tuning
 OS generate log files containing error information
 Failure of an application can generate core dump file capturing
memory of the process
 Operating system failure can generate crash dump file containing
kernel memory
 Beyond crashes, performance tuning can optimize system
performance
 Sometimes using trace listings of activities, recorded for analysis
 Profiling is periodic sampling of instruction pointer to look for statistical
trends
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.”
 Improve performance by removing bottlenecks
 OS must provide means of computing and displaying
measures of system behavior
 For example, “top” program or Windows Task Manager
 Collects data for a specific event, such as steps involved
in a system call invocation
 Tools include
• strace – trace system calls invoked by a process
• gdb – source-level debugger
• perf – collection of Linux performance tools
• tcpdump – collects network packets
 Debugging interactions between user-level and kernel code nearly
impossible without toolset that understands both and an instrument
their actions
 BCC (BPF Compiler Collection) is a rich toolkit providing tracing
features for Linux
• See also the original DTrace
 For example, disksnoop.py traces disk I/O activity

 Many other tools (next slide)