LECTURE 2

OPERATING-SYSTEM STRUCTURES

Ch2 in course reference

DR.HEND MANCY
LECTURE OUTLINE

• Operating System Services

• User Operating System Interface
• System Calls
• Types of System Calls
• Operating System Design and Implementation
• Operating System Structure
• Operating System Debugging
• System Boot
A VIEW OF OPERATING SYSTEM SERVICES
 USER OPERATING SYSTEM INTERFACE

➢ 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.
 USER OPERATING SYSTEM INTERFACE CONT.
➢ User-friendly desktop GUI
• Usually mouse, keyboard, and monitor
• Icons represent files, programs, actions, etc
➢ 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).
➢Voice commands
 SYSTEM CALLS

• System call offers the services of the operating system to the user
programs.

• That is via API (Application Programming Interface).

• System calls are the only entry points for the kernel system.

• Typically written in a high-level language (C o, C++ or Python)

• 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).
TYPES OF SYSTEM CALLS (6)

• Process Control

• File Management

• Device Management

• Information Maintenance

• Communications

• Protection
IMPORTANT SYSTEM CALLS USED IN OS
EXAMPLE OF STANDARD API
HOW SYSTEM CALL WORKS?
API – SYSTEM CALL – OS RELATIONSHIP
 SYSTEM CALL PARAMETER PASSING

• Often, more information is required than simply identity of

desired system call.
Three general methods used to pass parameters to the OS:
• Simplest: pass the parameters in 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.
Note that, Block and stack methods do not limit the number or
length of parameters being passed.
PARAMETER PASSING VIA BLOCK
 TYPES OF SYSTEM CALLS

• 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
 TYPES OF SYSTEM CALLS (CONT.)
• 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.
• Protection
• Control access to resources
• Get and set permissions
• Allow and deny user access
 TYPES OF SYSTEM CALLS (CONT.)

• 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
 SYSTEM PROGRAMS
System programs provide a convenient environment for program
development and execution. Some of them are simply user interfaces others are
considerably more complex.

They can be divided into:

• File manipulation
• Status information sometimes stored in a File modification
• Programming language support
• Program loading and execution
• Communications
• Background services
• Application programs
Note that, Most users’ view of the operation system is defined by
system programs, not the actual system calls.
 SYSTEM CALL VS SYSTEM PROGRAMS

• System calls allow user-level processes to request some services

from the operating system which process itself is not allowed to do.

• System programs provide basic functioning to users so that they do

not need to write their own environment for program development
(editors, compilers) and program execution (shells).
 OPERATING SYSTEM DESIGN AND IMPLEMENTATION
Design and Implementation of OS 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.
• Specifying and designing an OS is highly creative task of software engineering.
• Implementation 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.
 OPERATING SYSTEM STRUCTURE

• General-purpose OS is very large program

• Various ways to structure ones
• Simple structure – MS-DOS
• More complex -- UNIX
• Layered – an abstraction
• Microkernel -Mach
 SIMPLE STRUCTURE -- MS-DOS

• 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
NON-SIMPLE STRUCTURE ( UNIX )

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

• 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.
 LAYERED APPROACH

• The operating system is divided into several

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
MICROKERNEL SYSTEM STRUCTURE
• Moves as much from the kernel into user
space
• Mach 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
MODULES

• Many modern operating systems

implement loadable 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
• Linux, Solaris, etc
 HYBRID SYSTEMS

• Most modern operating systems are actually

graphical user interface not one pure model
Aqua
• Hybrid combines multiple approaches
to address performance, security,
usability needs
application environments and services
• Linux and Solaris kernels in kernel
address space, so monolithic, plus
Java Cocoa Quicktime BSD modular for dynamic loading of
functionality
• Windows mostly monolithic, plus
kernel environment
microkernel for different subsystem
BSD personalities
• Apple Mac OS X hybrid, layered, Aqua UI
Mach plus Cocoa programming environment
• Below is kernel consisting of Mach
microkernel and BSD Unix parts, plus
I/O kit kernel extensions I/O kit and dynamically loadable
modules (called kernel extensions)
 EXAMPLE : IOS

Apple mobile OS for iPhone, iPad Structured on Mac

OS X.

• Cocoa Touch Objective-C API for developing apps

• Media services layer for graphics, audio, video
• Core services provides cloud computing, databases
• Core operating system, based on Mac OS X kernel
 EXAMPLE: ANDROID
Applications

• Developed by Google (Open Source)

Application Framework • Similar stack to IOS.

• Based on Linux kernel but modified
• Provides process, memory, device-driver
management
Libraries Android runtime
• Adds power management
SQLite openGL Core Libraries • Runtime environment includes core set of
libraries and Dalvik virtual machine.
• Apps developed in Java plus Android API
surface media
Dalvik • Java class files compiled to Java
manager framework
virtual machine bytecode then translated to executable
than runs in Dalvik VM
webkit libc
• Libraries include frameworks for web browser
(webkit), database (SQLite), multimedia, smaller
libc
Linux kernel
 OPERATING-SYSTEM DEBUGGING

• Debugging is finding and fixing errors, or bugs

• 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.”
 PERFORMANCE TUNING

• Improve performance by removing

bottlenecks
• OS must provide means of
computing and displaying measures
of system behavior
• For example, Windows Task
Manager
DTRACE

DTrace tool in Solaris,

FreeBSD, Mac OS X allows
live instrumentation on
production systems
Probes fire when code is
executed within a provider,
capturing state data and
sending it to consumers of
those probes

Example of following
XEventsQueued system call
move from libc library to
kernel and back
DTRACE (CONT.)

DTrace code to record

amount of time each
process with UserID 101 is
in running mode (on CPU)
in nanoseconds
 SYSTEM BOOT

• When power initialized on system,

execution starts at a fixed memory
location; ROM used to hold initial boot
code.
• OS must be made available to
hardware so hardware can start it.
• Small piece of code boot loader
stored in ROM locates the kernel,
loads it into memory, and starts it.
• Kernel loads and system is then
running
THE END