O P E R AT I N G S Y S T E M S T R U C T U R E S

O P E R AT I N G S Y S T E M S T R U C T U R E S
 Operating System Services
 User Operating System Interface

 System Calls

 Types of System Calls

 Operating System Structure

 O P E R AT I N G S Y S T E M S E R V I C E S
 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 Interface (CLI), which uses

text commands and a method for entering them.

 Batch interface, in which commands and

directives to control those commands are entered
into files, and those files are executed.
O P E R AT I N G S Y S T E M S E R V I C E S
 Graphical User Interface (GUI): Here, 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.
Some systems provide two or all three of these
variations.

● 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).
O P E R AT I N G S Y S T E M S E RV I C E S
● I/O operations - A running program may require
I/O, which may involve a file or an I/O device. For
specific devices, special functions may be desired
(such as recording to a C D or DV D drive or
blanking a display screen). For efficiency and
protection, the operating system must provide a
means to do I/O.

● 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 based on file ownership.
O P E R AT I N G S Y S T E M S E RV I C E S
● C ommunications P rocesses 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).
● E rror detection – O S needs to be
constantly aware of possible errors.
 May occur in the C P U and memory hardware, in

I/O devices, in user program.

 F or each type of error, O S should take
appropriate action to ensure correct the
consistent computing. and
 Debugging facilities can greatly enhance the
user’s and programmer’s abilities to efficiently use
the system.
O P E R AT I N G S Y S T E M S E RV I C E S
 Another set of O S 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.
 O S manages many different types of resources.

Some ( C P U cycles, main memory, file

storage) may have special allocation code,
whereas others (such as I/O devices) may
have much more general request and
release code.

● Accounting - To keep track of which users use

how much and what kinds of computer
resources.
O P E R AT I N G S Y S T E M S E RV I C E S
 This keeping may be used for
accumulating
record usage statistics. U sage
statistics may be a valuable tool for
researchers who wish to reconfigure the
system to improve computing services.
● 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.
O P E R AT I N G S Y S T E M S E RV I C E S
USER AND O P E R AT I N G - S Y S T E M I N T E R FA C E - C L I
 C L I or command interpreter, that allows users
to directly enter commands to be performed by the
operating system.
● Some operating systems include the command
interpreter in the kernel. Others, such as
Windows and U N IX , treat the command
interpreter as a special program
running when a jobthat is
is initiated or when
a user first logs.

● On systems with multiple command interpreters to

choose from, the interpreters are known as shells.
 For example, on U N I X and Linux systems, a

user may choose among several different shells,

including the Bourne shell, C shell, Bourne-
Again shell, Korn shell, and others.
USER AND O P E R AT I N G - S Y S T E M I N T E R FA C E - C L I
● The main function of the command interpreter
is to get and execute the next user-specified
command. Many of the commands given at this
level manipulate files: create, delete, list, print,
copy, execute, and so on.
● The M S - D O S and U N I X shells operate in this
way.

● These commands can be implemented in two

general ways.
1. The command interpreter itself contains
the code to execute the command.
2. Implements most commands through
system programs(Used by U N I X OS).
Example: rm file.txt
BOURNE S H EL L COMMAND INTERPRETER
USER AND O P E R AT I N G - S Y S T E M I N T E R FA C E - G U I
 A second strategy for interfacing with the operating
system is through a user friendly graphical user
interface, or G U I .

 Users employ a mouse-based, window and- menu

system characterized by a desktop metaphor.
The user moves the mouse to position its pointer
on images, or icons, on the screen (the desktop)
that represent programs, files, directories, system
functions, and open directory (known as a folder).
● Invented at Xerox PA RC .

● Microsoft’s first version of Windows – Version 1.0 –

was based on the addition of a G U I interface to the
M S - D O S operating system.
USER AND O P E R AT I N G - S Y S T E M I N T E R FA C E - G U I
 M any systems now include both C L I and
G U I interfaces.
● M icrosoft Windows is G U I with C L I
“command”
shell.
● Apple Mac (Macintosh) O S X is “ Aqua ” G U I
interface with U N I X kernel underneath and shells
available.
● Unix and Linux have C L I with optional G U I
interfaces. These include C D E (Common Desktop
Environment), K D E (K Desktop Environment),
GNOME)
T O U C H S C R E E N I N T E R FA C E S
 Touch screen devices require new interfaces
● Mouse not possible or not desired
● Actions and selection based on gestures (for
example, pressing and swiping fingers across the
screen.
● Virtual keyboard for text entry
 Voice commands.
T O U C H S C R E E N I N T E R FA C E S
THE MAC OS X GUI
CHOICE O F I N T E R FA C E
 The choice of whether to use a command-line or
G U I interface is mostly one of personal preference.
 System administrators who manage computers

and power users who have deep knowledge of a

system frequently use the command-line
interface.

 It is more efficient, giving them faster access to the

activities they need to perform.
 Command-line interfaces usually make repetitive

tasks easier, in part because they have their own

programmability.
 These shell scripts are very common on systems

that are command-line oriented, such as U N I X and

Linux.
CHOICE O F I N T E R FA C E
 Most Windows users are happy to use the Windows
G U I environment and almost never use the MS-
D O S shell interface.
SYSTEM C A L L S
 System call is a request made by the user in order
to get any kind of services from O S .

 Programming interface to the services provided by

the O S .
 These calls are available as routines written in a
high-level language (C or C++).
 An example to illustrate how system calls are used:
writing a simple program to read data from one file
and copy them to another file.
A ‘C’ P R O G R A M TO C O P Y T H E C O N T E N T S O F
O N E F I L E TO A N O T H E R F I L E
A ‘C’ P R O G R A M TO C O P Y T H E C O N T E N T S O F
O N E F I L E TO A N O T H E R F I L E
EXAMPLE OF SYSTEM C A L L S
 System call sequence to copy the contents of one file
to another file.
SYSTEM C A L L S
 Even simple programs may take heavy use of the
OS.
 Frequently, systems execute thousands of system
calls per second.

 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, P O S I X API for POSIX-based systems
(including virtually all versions of U N I X , Linux,
and Mac O S X), and Java API for the Java virtual
machine (JVM)
EXAMPLE OF S TA N DA R D A P I
SYSTEM C A L L I M P L E M E N TAT I O N
 Typically, a number associated with each system
call.

● System-call interface that serves as the link to

system calls made available by the O S .

● This interface maintains a table

indexed according to these numbers.

 The system call interface invokes the intended

system call in O S kernel and returns status of the
system call and any return values.
SYSTEM C A L L I M P L E M E N TAT I O N
 The caller need know about how the
nothing system call is
implemented.
● Just needs to obey API and understand what O S
will do as a result call.

● M ost details of O S interface hidden

from programmer by API.

 Managed by run-time support library (set of

functions built into libraries included with
compiler).
A P I - S Y S T E M C A L L – O S R E L AT I O N S H I P
SYSTEM C A L L PA R A M E T E R PA S S I N G
 O ften, more information is required than
simply identity of desired system call.
● E xact type and amount of information
vary according to O S and call.

 Three general methods used to pass parameters to

the O S .
● Simplest: pass the parameters in registers
 In some cases, may be more parameters than

registers.

● P arameters stored a block, or

in table, in memory, and address of
parameter inblock
a register.
passed as a
 This approach taken by Linux and Solaris.
SYSTEM C A L L PA R A M E T E R PA S S I N G

● 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.
PARAMETER PA S S I N G V I A TABLE
TYPES OF SYSTEM C A L L S
 System calls can be grouped roughly into six major
categories:
1. Process control,
2. File management,
3. Device management,
4. Information maintenance,
5. Communications, and
6. Protection.
TYPES OF SYSTEM C A L L S
 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 C A L L S
 A running program needs to be able to halt its
execution either normally (end()) or abnormally
(abort()).

 A process or job executing one program may want

to load() and execute() another program.

 A mechanism for one program to call another

program. If both programs continue concurrently,
we have created a new job or process to be
multiprogrammed, a system call specifically for this
purpose (create_process() or submit_job()).
TYPES OF SYSTEM C A L L S
 If we create a new job or process, or perhaps even a
set of jobs or processes, we should be able to control
its execution.

 This control requires the ability to determine and

reset the attributes of a job or process,
including the job’s priority, its maximum
allowable execution time, and so on.
(get_process _attributes(), set_process_attributes()).

 We may also want to terminate a job or process

that we created (terminate process()) if we find
that it is incorrect or is no longer needed.
TYPES OF SYSTEM C A L L S
 Having created new jobs or processes, we may need
to wait for them to finish their execution. We may
want to wait for a certain amount of time to pass
(wait_time()).

 We will want to wait for a specific event to occur

(wait event()). The jobs or processes should then
signal when that event has occurred (signal_
event()).

 A lock.
EXAMPLE: MS-DOS
 Single-tasking.
 Shell invoked when

system booted.
 Simple method to run

program.
● No process created.
 Single memory space.
 Loads program into

memory, overwriting
all but the kernel.
 Program exit -> shell At system running a
startup program
reloaded.
EXAMPLE: F R E E B S D
 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
TYPES OF SYSTEM C A L L S
 System call is an interface between process &os.
 File management

● create file, delete file.

● open, close file.
● read, write, reposition.
● get and set file attributes.

 We first need to be able to create() and delete() files.

Either system call requires the name of the file and
perhaps some of the file’s attributes.

 Once the file is created, we need to open() it and to use

it. We may also read(), write(), or reposition()
(rewind or skip to the end of the file, for example).
 Finally, we need to close() the file, indicating that we

are no longer using it.

TYPES OF SYSTEM C A L L S
 File attributes include the file name, file type,
protection codes, accounting information, and so on.
At least two system calls, get_file_attributes()
and set_file_attributes(), are required for this
function.

 Device management
● request device, release device.
● read, write, reposition.
● get device attributes, set device attributes.
● logically attach or detach devices.
TYPES OF SYSTEM C A L L S
 A process may need several resources to
execute – main memory, disk drives, access to
files, and so on.
 The various resources controlled by the
operating system can be thought of as devices.

 Some of these devices are physical devices (for

example, disk drives), while others can be thought of
as abstract or virtual devices (for example, files).

 A system with multiple users may require us to first

request() a device, to ensure exclusive use of it.
After we are finished with the device, we release()
it. These functions are similar to the open() and
close() system calls for files.
TYPES OF SYSTEM C A L L S
 Once the device has been requested (and allocated to
us), we can read(), write(), and (possibly)
reposition() the device, just as we can with files.

 Information maintenance
● get time or date, set time or date.
● get system data, set system data.
● get and set process, file, or device attributes.

 Many system calls exist for transferring information

between the user program and the operating system.
● E xample: M ost systems have a system
call to return the current time() and date().
TYPES OF SYSTEM C A L L S
 Other system calls may return information about the
system, such as the number of current users, the
version number of the operating system, the
amount of free memory or disk space, and so on.

 A set of system calls is helpful in debugging a

program. Many systems provide system calls to dump()
memory, which is useful for debugging. A program
trace lists each system call as it is executed.

 The O S keeps information about all its processes, and

system calls are used to access this information.
Generally, calls are also used to reset the process
information (get_ process_ attributes()
and set_process_attributes()).
TYPES OF SYSTEM C A L L S
 Communications: There are two models of
interprocess communication:
● Message passing model.
● Shared-memory model.

● 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
TYPES OF SYSTEM C A L L S
 The get_hostid() and get_processid() system
calls translate the process name to an identifier.
 The identifiers are then passed to open() and

close() calls provided by the file system or to

specific open_ connection()
and close_connection() system calls, depending
on the system’s model of communication.

 The recipient process usually must give its

permission for communication to take place with an
accept_connection() call.

 They execute wait_for_connection() call and are

awakened when a connection is made.
TYPES OF SYSTEM C A L L S
 The client, and the server, exchange messages by
using read_message() and write_message()
system calls.
 The close_connection() call terminates the

communication.

 In the shared-memory model, processes use

shared_ memory_ create()
and shared_memory_attach() system calls to
create and gain access to regions of memory owned
by other processes.
TYPES OF SYSTEM C A L L S
 Protection
● Control access to resources.
● Get and set permissions.
● Allow and deny user access.
EXAMPLES OF UNIX AND W I N D OWS S Y S T E M
CALLS
S TA N DA R D C L I B R A RY E X A M P L E
 C program invoking printf() library call, which
calls write() system call
Operating system Structure

A Large and complex modern operating system must be

engineered,carefully ,to function properly and be modified
easily.
Partion the large task into small components,or modules.
Each of these modules should be a well-defined portion of
the system,with carefully defined inputs,outputs,and
functions.
There are 4 different structures based on how components
are interconnected into a kernel.
Simple Structure
Monolitic
Layered Approach
Microkernels
Modules
 SIMPLE STRUC TURE -MS-DOS Layer Str ucture
 Many operating systems do not
have well-defined structures.
 This type of OS is small.
simple ,and limited systems
 M S - D O S –is an example of such

system.
 The interfaes and levels of
functionality are not well
seprated.
 It is a single programming
system(at a time only (one-
disadv))
 Application programs are able to

access the basic I/O routines to

write directly to the display and
disk drives.
SIMPLE STRUCTURE contd. .

Hence ,MS-DOS vulnerable to malicious

programs, causing entire system crashes when
programs fail.
MS-DOS was also limited by the hardware.
The Intel 8088 for which it was
written ,provides no dual mouse and no
hardware Protection.
MONOLITHIC STRUCTURE - UNIX
 U N IX – limited hardware functionality, the
by original U N I X operating system had limited
structuring.

 The U N I X O S consists of two separable parts

● Systems programs

● The kernel
 C onsists everything below the system-call
of
interface and above the physical hardware.
 P rovides file system, C P U scheduling,
memory
the management, and other operating-
system functions; a large number of functions
for one level.
MONOLITHIC STRUCTURE - UNIX
 Taken in sum, that is an enormous amount of
functionality to be combined into one level.
This monolithic structure was difficult to
implement and maintain.

Sym programs
L AY E R E D A P P ROAC H
 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.

 The main advantage of the layered approach is

simplicity of constructi on and debugging.

 The Design and implementati on of the system are
simplifi ed.
• Because a layer can use
only lower –level layers,
• Careful planning is necessary.
L AY E R E D A P P ROAC H
 With modularity, layers are selected such that each
uses functions (operations) and services of only lower-
level layers.
 E a c h layer is implemented only with operations

provided by lower-level layers.

 Each layer hides the existence of certain data

structures, operations, and hardware from higher-
level layers.
 The major difficulty with the layered approach

involves appropriately defining the various

layers.

 A final problem with layered implementations is that

they tend to be less efficient than other types.
MICROKERNELS
 In the mid-1980s, an operating system called Mach
that modularized the kernel using the microkernel
approach.

 This method structures the operating system by

removing all nonessential components from the
kernel and implementing them as system and
user-level programs.

 The main function of the microkernel is to provide

communication between the client program
and the various services that are also running
in user space.
MICROKERNELS

 C ommunication is provided through

message passing.
MICROKERNELS

 Benefits:
● It makes extending the operating system easier
without modifying the kernel.
● Portable from one hardware design to
a n o t h e r.
● More reliable (less code is running in kernel mode).
● More secure.
 Disadvantage:
● P erformance of user space to kernel
overhead space
communication.
MODUL E S
 Many modern operating systems
loadable kernel modules implement
approach. - uses object-oriented

 Here, the kernel has a set of core components

and links in additional services via modules,
either at boot time or during run time.

 This type of design is common in modern

implementations of U N I X , such as Solaris, Linux, and
Mac O S X, as well as Windows.

 The idea of the design is for the kernel to provide

core services while other services are
implemented dynamically, as the kernel
running. is
MODUL E S
 Operating system structure is organized around a
core kernel with seven types of loadable kernel
modules.
 It resembles the layered system in such a way that
each kernel section has defined protected
interfaces; but it is more flexible than a layered
system, because any module can call any other
module.

Solaris loadable
modules
MODUL E S

 The approach is also similar to the microkernel

approach in that the primary module has only core
functions and knowledge of how to load and
communicate with other modules; but it is more
efficient, because modules do not need to invoke
message passing in order to communicate.
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 O S X uses a hybrid structure. It is a

layered system.
 Aqua U I plus and a set of application environments

and services.
 The Cocoa environment specifies an API for the

Objective-C programming language, which is used for

writing Mac O S X applications.
MAC OS X
● Below is kernel environment consisting of Mach
microkernel (provides memory management) and
B S D Unix parts, plus I/O kit and dynamically
loadable modules (called kernel extensions)

The Mac OS X
structure.
IOS
 Apple mobile O S for iPhone, i Pa d
● Structured on Mac O S X , added functionality.
● Does not run O S X applications natively.
 Also runs on different C P U 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 O S X kernel.

Architecture of Apple’s iOS .

A N D R O ID
 Developed by Open Handset Alliance (mostly Google)
for Android smartphones and tablet computers.
● Open Source
 Similar stack to iOS.

 Based on Linux kernel but modified.

● P rovides 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
 J ava class files compiled to J ava
bytecode then translated to executable than
runs in Dalvik V M
 L ibraries include frameworks for web
browser (webkit), database (SQLite), multimedia,
ANDROID ARCHITECTURE