Operating-System

Structures
Operating-System Structures
• Operating System Services
• System Calls
• Types of System Calls
• System Programs

Ms.U.Elakkiya AP/IT 2
System call
• To understand system calls, first one needs to understand
the difference between kernel mode and user mode of a
CPU.
• Every modern operating system supports these two modes.

Ms.U.Elakkiya AP/IT 3
 Contd..
Kernel Mode:
When CPU is in kernel mode, the code being executed can access any
memory address and any hardware resource.
Hence kernel mode is a very privileged and powerful mode.
If a program crashes in kernel mode, the entire system will be halted.
User Mode:
When CPU is in user mode, the programs don’t have direct access to
memory and hardware resources.
In user mode, if any program crashes, only that particular program is
halted.
That means the system will be in a safe state even if a program in user
mode crashes.
Hence, most programs in an OS run in user mode.

Ms.U.Elakkiya AP/IT 4
What is System call?
• Performing any Operation a user must have to Request for a
Service from the System
• For Making any Request a user will prepare a Special call
which is also known as the System Call.
• The System Call is the Request for Running any Program and
for Performing any Operation on the System.
• When a user First Time Starts the System then the System is
in the user Mode and When he request For a Service then
the User Mode will be Converted into the Kernel Mode
Which just Listen the Request of the user and Process the
Request and Display the Results those are Produced after the
Processing.

Ms.U.Elakkiya AP/IT 5
Example of System Calls
• System call sequence to copy the contents of one file
to another file

Ms.U.Elakkiya AP/IT 6
How System Calls works?
• Provides an interface to the services available by the OS
• Typically written in a high-level language (C or C++)
• How System calls are used?
• Writing a simple program to read data from one file and
copy it to another file.
• Input that the program needs two file names -> input and
output file
• One approach is for the program to ask the user for the
names.
• Another approach is an interactive system, by prompting
message on the screen.
• Another approach is mouse-based or icon-based systems.

Ms.U.Elakkiya AP/IT 7
Example of Standard API

Ms.U.Elakkiya AP/IT 8
System Call Implementation
• Typically, a number 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)

Ms.U.Elakkiya AP/IT 9
API – System Call – OS Relationship

Ms.U.Elakkiya AP/IT 10
Methods of passing parameter
3 simple Methods:
•Pass the parameters in registers -> direct
method
•Parameters are stored in block or table and the
address of the block is passed
•Parameters can also be placed onto stack and
popped out

Ms.U.Elakkiya AP/IT 11
 System Call Parameter Passing

• 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

Ms.U.Elakkiya AP/IT 12
Parameter Passing via Table

Ms.U.Elakkiya AP/IT 13
Types of System call
• System calls can be grouped into six
categories:
• Process control
• File manipulation
• Device manipulation
• Information maintenance
• Communications

Ms.U.Elakkiya AP/IT 14
Types of System Calls
• Process control
Process
• create process, terminate process Control
• 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

Ms.U.Elakkiya AP/IT 15
Types of System Calls

• 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

Ms.U.Elakkiya AP/IT 16
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

Ms.U.Elakkiya AP/IT 17
Standard C Library Example
• C program invoking printf() library call, which calls write() system
call

Ms.U.Elakkiya AP/IT 18
 SYSTEM PROGRAM
• An important aspect of a modern system is the collection of
system programs

Ms.U.Elakkiya AP/IT 19
System Programs
• System programs-a program, as an operating system,
compiler, or utility program, that controls some aspect of
the operation of a computer
• provide a convenient environment for program
development and execution. They can be divided into:
• File management
• Status information sometimes stored in a File
modification
• Programming language support
• Program loading and execution
• Communications
• Background services
• Application programs

Ms.U.Elakkiya AP/IT 20
System Programs
• 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

Ms.U.Elakkiya AP/IT 21
 System Programs (Cont.)
• 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 are provided with OS
• 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

Ms.U.Elakkiya AP/IT 22
 System Programs (Contd.)
• 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

Ms.U.Elakkiya AP/IT 23
Operating System Structure
• The design of an operating system architecture
traditionally follows the separation of concerns
principle.
• This principle suggests structuring the operating
system into relatively independent parts that provide
simple individual features, thus keeping the
complexity of the design manageable.
• Various ways to structure ones
• Simple structure – MS-DOS
• More complex -- UNIX
• Layered – an abstracation
• Microkernel –Mach
• Modular

Ms.U.Elakkiya AP/IT 24
1.Simple Structure
• When DOS was originally written its developers
had no idea how big and important it would
eventually become
• It was written by a few programmers in a
relatively short amount of time, without the
benefit of modern software engineering
techniques, and then gradually grew over time to
exceed its original expectations.
• It does not break the system into subsystems,
and has no distinction between user and kernel
modes, allowing all programs direct access to
the underlying hardware

Ms.U.Elakkiya AP/IT 25
Simple Structure -- MS-DOS

Ms.U.Elakkiya AP/IT 26
Traditional UNIX System Structure-
Monolithic
Beyond simple but not fully layered

Ms.U.Elakkiya AP/IT 27
Layered Approach

Ms.U.Elakkiya AP/IT 28
 2.Layered Approach
• Another approach is to break the OS into a number of
smaller layers
• This approach allows each layer to be developed and
debugged independently, with the assumption that all
lower layers have already been debugged and are trusted
to deliver proper services.
• The bottom layer (layer 0) is the hardware layer and the
highest layer (layer n) is the user interface layer
• The problem is deciding what order in which to place
the layers, as no layer can call upon the services of any
higher layer
• Layered approaches can also be less efficient, as a
request for service from a higher layer has to filter
through all lower layers before it reaches the HW,
possibly with significant processing at each step.
Ms.U.Elakkiya AP/IT 29
Contd..
• The layered are selected such that each user functions and
services of only lower level layer
• The first layer can be debugged without any concern for
the rest of the system
• It user basic hardware to implement this function once the
first layer is debugged., it’s correct functioning can be
assumed while the second layer is debugged & so on
• If an error is found during the debugged of particular
layer, the layer must be on that layer, because the layer
below it already debugged. Because of this design of the
system is simplified when operating system is broken up
into layer.

Ms.U.Elakkiya AP/IT 30
Contd..
• OS/2 operating system is example of layered
architecture of operating system another example
is earlier version of Windows NT.
• The main disadvantage of this architecture is that it
requires an appropriate definition of the various
layers & a careful planning of the proper
placement of the layer.

Ms.U.Elakkiya AP/IT 31
3.Microkernels

Ms.U.Elakkiya AP/IT 32
Microkernels
• The basic idea behind micro kernels is to remove all
non-essential services from the kernel, and implement
them as system applications instead, thereby making the
kernel as small and efficient as possible.
• Most microkernels provide basic process and memory
management, and message passing between other
services, and not much more.
• Security and protection can be enhanced, as most
services are performed in user mode, not kernel mode.
• System expansion can also be easier, because it only
involves adding more system applications, not rebuilding
a new kernel.

Ms.U.Elakkiya AP/IT 33
Contd..
• The benefits of the microkernel
• Extending the operating system becomes much easier.
• Easier to port the operating system to new architectures
• More reliable (less code is running in kernel mode)
• The microkernel also provides more security and
reliability.

Ms.U.Elakkiya AP/IT 34
Microkernel architecture

Ms.U.Elakkiya AP/IT 35
Microkernel System Structure

Ms.U.Elakkiya AP/IT 36
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

Ms.U.Elakkiya AP/IT 37
Solaris Modular Approach

Ms.U.Elakkiya AP/IT 38
Hybrid Systems
• Most modern operating systems are actually 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)

Ms.U.Elakkiya AP/IT 39
Mac OS X Structure

Ms.U.Elakkiya AP/IT 40
 iOS
• Apple mobile OS for iPhone, iPad
• Structured on Mac OS X, added functionality
• Does not run OS X applications natively
• Also runs on different CPU architecture
(ARM vs. Intel)
• 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

Ms.U.Elakkiya AP/IT 41
Android
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 than runs in Dalvik VM
Libraries include frameworks for web browser (webkit),
database (SQLite), multimedia, smaller libc

Ms.U.Elakkiya AP/IT 42
Android Architecture

Ms.U.Elakkiya AP/IT 43
 Operating System Generation

Operating systems are designed to run on any of a

class of machines; the system must be configured for
each specific computer site
SYSGEN program obtains information concerning the
specific configuration of the hardware system
Used to build system-specific compiled kernel or
system-tuned
Can general more efficient code than one general
kernel

Ms.U.Elakkiya AP/IT 44
System Boot
• The general approach when most computers boot up goes
something like this:
• When the system powers up, an interrupt is generated which
loads a memory address into the program counter, and the
system begins executing instructions found at that address.
This address points to the "bootstrap" program located in
ROM chips ( or EPROM chips ) on the motherboard.
• The ROM bootstrap program first runs hardware checks,
determining what physical resources are present and doing
power-on self tests ( POST ) of all HW for which this is
applicable. Some devices, such as controller cards may have
their own on-board diagnostics, which are called by the ROM
bootstrap program.

Ms.U.Elakkiya AP/IT 45
Contd..
• The user generally has the option of pressing a special key
during the POST process, which will launch the ROM BIOS
configuration utility if pressed. This utility allows the user to
specify and configure certain hardware parameters as where to
look for an OS and whether or not to restrict access to the utility
with a password.
• Some hardware may also provide access to additional
configuration setup programs, such as for a RAID disk
controller or some special graphics or networking cards.
• Assuming the utility has not been invoked, the bootstrap
program then looks for a non-volatile storage device
containing an OS. Depending on configuration, it may look for
a floppy drive, CD ROM drive, or primary or secondary hard
drives, in the order specified by the HW configuration utility.

Ms.U.Elakkiya AP/IT 46
Contd..
• Assuming it goes to a hard drive, it will find the first
sector on the hard drive and load up the fdisk table,
which contains information about how the physical hard
drive is divided up into logical partitions, where each
partition starts and ends, and which partition is the
"active" partition used for booting the system.
• There is also a very small amount of system code in the
portion of the first disk block not occupied by the fdisk
table. This bootstrap code is the first step that is not built
into the hardware, i.e. the first part which might be in
any way OS-specific. Generally this code knows just
enough to access the hard drive, and to load and execute
a ( slightly ) larger boot program.

Ms.U.Elakkiya AP/IT 47
 Contd..
• For a single-boot system, the boot program loaded off of the hard disk
will then proceed to locate the kernel on the hard drive, load the kernel
into memory, and then transfer control over to the kernel. There may
be some opportunity to specify a particular kernel to be loaded at this
stage, which may be useful if a new kernel has just been generated and
doesn't work, or if the system has multiple kernels available with
different configurations for different purposes. ( Some systems may
boot different configurations automatically, depending on what
hardware has been found in earlier steps. )
• For dual-boot or multiple-boot systems, the boot program will give the
user an opportunity to specify a particular OS to load, with a default
choice if the user does not pick a particular OS within a given time
frame. The boot program then finds the boot loader for the chosen
single-boot OS, and runs that program as described in the previous
bullet point.

Ms.U.Elakkiya AP/IT 48