Chapter 2: Design Principles
Functionality of a typical OS
1. Manage the computer's resources, such as the
central processing unit, memory, disk drives, and
printers,
2. Establish a user interface, and
3. Execute and provide services for applications
software.
• Keep in mind, however, that much of the work of an
operating system is hidden from the user; many
necessary tasks are performed behind the scenes.
Design Issues
• Efficiency
Most I/O devices slow compared to main memory
(and the CPU)
Use of multiprogramming allows for some processes to
bewaiting on I/O while another process executes
Often I/O still cannot keep up with processor speed
Swapping may used to bring in additional Ready processes
--More I/O operations
Optimize I/O efficiency – especially Disk &
Network I/O
Robustness
The system is robust if the addition of a feature doesn't
cause the breakdown of a previous feature.
In the case of a robust design, there is no implication
that other parts of the design (or features) would be
shaped by the addition of a new one... to the contrary,
robustness implies a certain rigidity, such that the
original features will be there no matter what you
change in other areas.
In a good, robust OS, there's no way to crash or
damage one part of the OS by crashing or adding
insane features to another part.
Flexibility
• Flexible operating systems are taken to be
those whose designs have been motivated to
some degree by the desire to allow the system
to be tailored, either statically or dynamically,
to the requirements of specific applications or
application domains.
• So how does it work ?
• The use of object orientation is a common
feature of many flexible operating systems.
Security
• Authentication: Clients , Servers and messages must
be authenticated.
• Operating system authentication (OS authentication)
is a way of using operating system login credentials
to authenticate database users.
• One aspect of OS authentication can be used to
authenticate database administrators.
• OS authentication is needed because there must be a
way to identify administrative users even if the
database is shut down.
• Authorization: Access control has to be performed
across a physical network with heterogeneous
components under different administrative units
using different security models.
Compatibility
• While the basic operations of a kernel are of
supreme interest to researchers in the operating
system area, most people do not want to know
what is going on as long as their programs work. As
such, one of the most important features of an
operating system is the lack of surprises it offers to
the user, be he a normal end-user or a
programmer. Even new features should be offered
as a superset, rather than instead of functionality
that the user is accustomed to.
Structuring Methods
Kernels
• The part of the OS critical to correct operation
(trusted software)
• Executes in supervisor mode
• The trap instruction is used to switch from
user to supervisor mode, entering the OS
Operating Systems: A Modern Perspe
ctive, Chapter 3
Supervisor and User Memory
User
User User
User
Process
Process Space
Space
Supervisor
Supervisor
Process
Process
Supervisor
Supervisor
Space
Space
Operating Systems: A Modern Perspe
ctive, Chapter 3
Structuring Methods
Monolithic Systems
• In this approach, the entire operating systems run as a
single program in kernel mode.
• The operating system is written as a collection of
procedures, linked together into a single large
executable binary program.
• When this technique is used, each procedure in the
system is free to call any other one, if the latter
provides some useful computation that the former
needs.
• Having thousands of procedures that can call each
other without restriction often leads to a system
unwieldy and difficult to understand.
Continued…
• To construct the actual object program of the
operating system when this approach is used,
one first compiles all the individual procedures
(or the files containing the procedures) and
then binds them all together into a single
executable file using the system linker.
• In terms of information hiding, there is
essentially none—every procedure is visible to
every other procedure
General OS Structure
App App App
API
File Memory Process Network
Systems Manager Manager Support
Security Service
Module Module
Extensions & Device Interrupt Boot &
Add’l device drivers Drivers handlers init
Monolithic Structure
Layered Systems
• Organize the operating system as a hierarchy
of layers, each one constructed upon the one
below it.
• Example:
• THE (Technische Hogeschool Eindhoven)
• MULTICS system
Layered Structure
• OS divided into number of layers
– bottom layer (layer 0), is the hardware
– highest (layer N) is the user interface
– each uses functions and services of only lower-level layers
• Advantages:
– Simplicity of construction
– Ease of debugging
– Extensible
• Disadvantages:
– Defining the layers
– Each layer adds overhead
Microkernels
• The basic idea behind the microkernel design is to
achieve high reliability by splitting the operating
system up into small, well-defined modules, only
one of which—the microkernel—runs in kernel
mode and the rest run as relatively powerless
ordinary user processes.
• They are especially common in real-time,
industrial, avionics, and military applications that
are mission critical and have very high reliability
requirements.
Microkernel Structure
• Moves as much from kernel into “user” space
• User modules communicate 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
– Example: Mach, QNX
• Detriments:
– Performance overhead of user to kernel space communication
– Example: Evolution of Windows NT to Windows XP
Microkernel Structure
App Memory App
Manager
Process Security
Manager Module
File
Systems Network
Support
Basic Message Passing Support
Extensions & Device Interrupt Boot &
Add’l device drivers Drivers handlers init
Modules
• Most modern OSs 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 with more flexible
• Examples: Solaris, Linux, MAC OS X
Resource Abstraction
• Provides an abstract model of the operation of hardware
components
– Like data abstraction in Object-Oriented programming
• Interface functions
• Internal functions and status
• Eliminates the tedious details that a programmer would
otherwise have to handle
• It is an extended machine providing abstraction of the
hardware
Hides the messy details which must be performed
Presents user with a virtual machine, easier to use
19
Process abstraction
• Running program, stream of running instructions + process state
A key OS abstraction: the applications you use are built of
processes
Shell, powerpoint, gcc, browser, …
• Easy to use
Processes are protected from each other
process = address space
Hide details of CPU, when&where to run
• Process abstraction of CPU/memory use
Address space
Thread abstraction of CPU within address space
API
The interface to the services provided by the OS has two parts:
1. Higher language interface – a part of a system
library
• Executes in user mode
• Implemented to accept a standard procedure call
• Traps to the Part 2
2. Kernel part
• Executes in system mode
• Implements the required system service
• May cause blocking the caller (forcing it to wait)
• After completion returns back to Part 1 (may report the
success or failure of the call)
System Calls
• Programming interface to the services provided by
the OS
• Typically written in a higher-level language (C or C++)
• Mostly accessed by programs via a higher-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)
• Why use APIs rather than the native system calls?
(Note that the system-call names used in this text are generic names, not necessarily )
System API Standards
Three most common API standards are
POSIX API for POSIX-based systems (including virtually all versions of
UNIX, Linux, and Mac OS X)
Win32 API for Windows
Java API for the Java virtual machine (JVM)
out of this course scope
POSIX (IEEE 1003.1, ISO/IEC 9945)
Very widely used standard based on (and including) C-language
Defines both
system calls and
compulsory system programs together with their functionality and
command-line format
– E.g. ls –w dir prints the list of files in a directory in a ‘wide’ format
Complete specification is at
http://www.opengroup.org/onlinepubs/9699919799/nframe.html
Win32 (Micro$oft Windows based systems)
Specifies system calls together with many Windows GUI routines
VERY complex, no really complete specification
Interrupt Handling
• One big responsibility of an operating system
is to handle hardware connected to the
machine
– Hard drives, keyboards and mice, wireless radios,
and karaoke microphones
• Processors are usually much faster than
devices
Interrupts
• Prevent CPUs from busy waiting
• A signal that the hardware can send when it
wants the CPU’s attention
• Need to pay attention to concurrency issues
Interrupts
• Interrupts are external events that require the processor’s
attention.
– Peripherals and other I/O devices may need attention.
– Timer interrupts to mark the passage of time.
• These situations are not errors.
– They happen normally.
– All interrupts are recoverable:
• The interrupted program will need to be resumed after the interrupt is handled.
• It is the operating system’s responsibility to do the right thing,
such as:
– Save the current state.
– Find and load the correct data from the hard disk
– Transfer data to/from the I/O device.
26
General Interrupt Flow
1. Completes current instruction
2. Saves current state to status registers
3. Identify source
4. Jump to and activate Interrupt Service Routing (ISR)
5. Return to original program (RTI) and restore state
Register
CPU Interrupt driven
I/O I/O
device device
27
End of Chapter 2
