0% found this document useful (0 votes)
11 views28 pages

Design Principles

Chapter 2 discusses the design principles of operating systems, focusing on functionality, efficiency, robustness, flexibility, security, compatibility, and structuring methods. It outlines various OS structures such as monolithic, layered, and microkernel designs, emphasizing the importance of resource abstraction and process management. Additionally, it covers system calls, API standards, and interrupt handling as critical aspects of OS operation and user interaction.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views28 pages

Design Principles

Chapter 2 discusses the design principles of operating systems, focusing on functionality, efficiency, robustness, flexibility, security, compatibility, and structuring methods. It outlines various OS structures such as monolithic, layered, and microkernel designs, emphasizing the importance of resource abstraction and process management. Additionally, it covers system calls, API standards, and interrupt handling as critical aspects of OS operation and user interaction.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 28

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

You might also like