OPERATING SYSTEMS

Chapter 2 -
Operating System Structures
CS3104-Operating Systems
Syed Sherjeel Ahmad Gilani
Operating-System Structures
 Operating System Services
 User Operating System Interface
 System Calls
 Types of System Calls
 System Programs
 Operating System Design and Implementation
 Operating System Structure
 Virtual Machines
 System Boot

2
Objectives
 To describe the services an operating system
provides to users, processes, and other
systems

 To discuss the various ways of structuring an

operating system

 To explain how operating systems are installed

and customized and how they boot

3
A View of Operating System Services

4
Operating System Services
 Operating systems provide an environment for
execution of programs and services to programs
and users
 Following are the operating-system services
provided to the users:
 User interface - Almost all operating systems
have a user interface (UI). Varies between
 Command-Line (CLI),
 Graphics User Interface (GUI),
 Batch

5
Operating System Services
 Program execution - The system must be able
to load a program into memory and to run that
program, end execution, either normally or with
error
 I/O operations - A running program may require
I/O, which may involve a file or an I/O device
 File-system manipulation - Programs need to
read and write files and directories, create and
delete them, search them, list file Information,
permission management.

6
Operating System Services (Cont.)
 Communications – Processes may exchange
information, on the same computer or between
computers over a network
 Communications may be via shared memory or through
message passing
 Error detection – OS needs to be constantly
aware of possible errors
 May occur in the CPU and memory hardware, in I/O
devices, in user program
 For each type of error, OS should take the appropriate
action to ensure correct computing
 Debugging facilities can greatly enhance the user’s and
programmer’s abilities to efficiently use the system

7
Operating System Services (Cont.)
 Another set of OS 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
Many types of resources:
Some may have special allocation code,
(i.e. CPU cycles, main memory, and file storage)
others may have general request and release code
(i.e. I/O devices)
 Accounting - To keep track of which users use how much
and what kinds of computer resources

8
Operating System Services (Cont.)
 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
 If a system is to be protected and secure,
precautions must be instituted throughout it.
 A chain is only as strong as its weakest link.

9
User OS Interface - CLI
 Command Line Interface (CLI) or command
interpreter allows direct command entry
 Sometimes implemented in kernel, sometimes by
systems program (e.g. Windows, Linux)
 Sometimes multiple flavors implemented – shells
 Primarily fetches a command from user and
executes it
 Sometimes commands built-in, sometimes just
names of programs
 In second case, adding new features doesn’t
require shell modification

10
User OS Interface - GUI
 User-friendly desktop interface
 Usually with mouse, keyboard, and monitor
 Icons represent files, programs, actions, etc.
 Various mouse buttons over objects in the interface cause
various actions (provide information, options, execute
function, open directory (folder)
 Invented at Xerox PARC (1973)
 Many systems now include both CLI and GUI
interfaces
 Microsoft Windows is GUI with CLI “command” shell
 Apple Mac OS X as “Aqua” GUI interface with UNIX kernel
underneath and shells available
 Solaris is CLI with optional GUI interfaces (Java Desktop,
KDE)
11
System Calls
 Programming interface to the services
provided by the OS
 Typically written in a high-level language (C
or C++)
 Mostly accessed by programs via a high-
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 almost all
versions of UNIX, Linux, and Mac OS X),
 Portable Operating System Interface (POSIX)
 Java API for the Java virtual machine (JVM)
12
Example of System Calls
 System call sequence to copy the contents of
one file to another file

13
Example of Standard API
 Consider the ReadFile() function in Win32 API

 Description of parameters passed to ReadFile()

 HANDLE file—the file to be read
 LPVOID buffer—a buffer where the data will be read into and written from
 DWORD bytesToRead—the number of bytes to be read into the buffer
 LPDWORD bytesRead—the number of bytes read during the last read
 LPOVERLAPPED ovl—indicates if overlapped I/O is being used

14
System Call Implementation
 Typically, a number is associated with each system
call
 System-call interface maintains a table indexed according to
these numbers
 The system call interface invokes intended system call
in OS kernel and returns status of the system call and
any return values
 The caller needs to know nothing about how the
system call is implemented
 Just needs to obey API and understand what OS will do as a
result of the 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)

15
API – System Call – OS Relationship

16
Standard C Library Example
 C program invoking printf() library call, which calls
write() system call

17
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
 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

18
Parameter Passing via Table

19
Types of System Calls
 Process control
 end, abort
 load, execute
 create process, terminate process
 get process attributes, set process attributes
 wait for time
 wait event, signal event
 allocate and free memory
 File management
 create file, delete file
 open, close file
 read, write, reposition
 get and set file attributes

20
Types of System Calls (Cont.)
 Device management
 request device, release device
 read, write, reposition
 get device attributes, set device attributes
 logically attach or detach devices
 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
 transfer status information

21 attach and detach remote devices
Windows & Unix System Calls

22
Program Execution in MS-DOS

(a) At system startup (b) Running a program

23
Example: MS-DOS
 Single-tasking OS
 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 reloaded

24
Example: FreeBSD UNIX
 Unix variant
 Multitasking OS
 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 means no error // return 0
 >0 means error code // return 1

25
FreeBSD Running Multiple Programs

26
System Programs
 System Programs (System Utilities) provide
a convenient environment for program
development and execution. They can be
divided into:
 File manipulation
 Status information
 File modification
 Programming language support
 Program loading and execution
 Communications
 Background Services
 Application programs
27
System Programs
 Some of them are simply user interfaces to
system calls; others are considerably more
complex
 File management - Create, delete, copy,
rename, print, dump, list, and generally
manipulate files and directories
 Status information
 System information e.g. date, time, amount of available
memory, disk space, number of users
 Detailed performance, logging, and debugging
information
 Format and print the output to the terminal or other
output devices
 Some systems implement a registry - used to store and
28
retrieve configuration information
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
 Program loading and execution- Absolute loaders,
relocatable loaders, linkage editors, debugging
systems for higher-level and machine language
 Communications - Provide the mechanism for
creating 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
 Background Services and Application Programs
29
OS Design and Implementation
 No consensus on design and implementation of
OS, but some approaches have proven successful
 Internal structure of different Operating Systems
vary widely
 Affected by choice of hardware & type of system
 User goals
 OS should be convenient to use, easy to learn, reliable,
safe, and fast
 System goals
 OS should be easy to design, implement, and maintain, as
well as flexible, reliable, error-free, and efficient

30
Policy vs. Mechanisms
 Policy is to decide what will be done
 Mechanism is to determine how to do
something

 The separation of policy from mechanism is

very important principle
 It allows maximum flexibility if policy decisions
are to be changed later

31
OS Implementation
 Early operating systems were written in assembly
language
 Operating System can be written in more than one
language
 lowest levels of the kernel might be assembly language
 Higher-level routines might be in C
 system programs might be in C or C++, in interpreted scripting
languages like PERL or Python, or in shell scripts
 High level language 
 the code can be written faster,
 more compact,
 easier to understand and debug
 For example,
 MS-DOS was written in Intel 8088 assembly language
 The Linux operating system, written mostly in C making it run on
32 different CPUs, including Intel X86, Oracle SPARC,and IBMPowerPC
OS Structure
Simple Structure e.g. MS-DOS
 Microsoft - Disk Operating System
 MS-DOS is designed on simple structure
 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

33
Layered Approach e.g. UNIX
 OS is divided into number of layers (levels)
 Each layer built on top of lower layers.

 The bottom most layer

(layer 0), is the hardware
 The highest (layer N)

is the user interface

34
UNIX
 Original UNIX operating system had limited
structuring
 UNIX OS consists of two separable layers
 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
 Monolithic Kernel
 Large number of functions for one level
35
Traditional UNIX System Structure

36
Microkernel System Structure
 Move as much functionality from kernel
space to user space
 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
37
Operating System Structure

38
Modular Approach
 Most modern OS implement kernel
modules
 Using object-oriented approach
 Each core component is separate
 Each talks to others using known interfaces
 Each is loadable as needed within the kernel

 Overall, similar to layers but with more

flexible

39
Modules
 Perhaps the best current methodology for
operating-system design involves using
loadable kernel modules.

 Kernel has a set of core components and

links in additional services via modules,
either at boot time or during run time
 E.g. Solaris, Linux, and Mac OS X, Windows

40
Solaris Loadable Modules

41
Hybrid Systems
 In practice, very few operating systems
adopt a single, strictly defined structure.
 Instead, they combine different structures,
resulting in hybrid systems
 that address performance, security, and
usability issues.
 E.g. Apple Mac OS X and the two most
prominent mobile operating systems—iOS
and Android

42
iOS – iPhone Operating System
 Not to confuse with Cisco IOS
 Company/Developer: Apple Inc.
 Programmed in: C, C++
 Apple does not license iOS for installation on non-
Apple hardware
 OS Family: OS X, Unix
 Source Model: Closed, + Open Source parts
 Latest Stable Release: 9
 Kernel Type: Hybrid (XNU) [Mono+Micro]
 User Interface: GUI
 iOS currently runs on iPhone, iPad, iPod touch and
Apple TV
[Source] http://en.wikipedia.org/wiki/IOS (2015-09-15)
43
The Mac OS X Structure

44
Architecture of Apple’s iOS

45
Android OS
 Company/Developer
 Google, Open Handset Alliance, Android Open
Source Project
 Programmed in C, C++, Java
 OS Family : Unix-like
 Source model : Open Source
 Initial release : September 23, 2008

Latest stable release : "Android 9 Pie",

August 6, 2018 as
[Source] https://en.wikipedia.org/wiki/Android_Pie (Dated: 22 October 2018)

46
Android platform architecture

47
Dalvik Virtual Machine
 It is developed by Dan Bornstein of Google.
 It is a type of JVM used in android devices to run apps
 Optimized for low processing power and low memory
environments.
 Unlike the JVM, the Dalvik Virtual Machine doesn’t
run .class files.
 It runs .dex files. .dex files are built from .class file at
the time of compilation and provides higher efficiency
in low resource environments.
 The Dalvik VM allows multiple instance of Virtual
machine to be created simultaneously providing
security, isolation, memory management and
threading support.

48
Virtual Machines
 Virtual Machines are logical extension of
layered approach
 A virtual machine provides an interface
identical to the underlying bare hardware
 Divides different operating systems into a
Host OS and number of Guest OS
 Host OS creates the illusion that a process
has its own processor and virtual memory
 Each Guest OS is provided with a (virtual)
copy of underlying hardware

49
Virtual Machines
 Commercially first appeared in IBM mainframes in
1972
 Fundamentally, multiple execution environments
(different operating systems) can share the same
hardware
 Protected from each other
 Some level of sharing of files can be permitted
 Communicate with each other and other physical
systems via networking
 Useful for development and testing
 Open Virtual Machine Format standard allows
a VM to run within many different virtual machine
(host) platforms
50
Virtual Machines Design

(a) Non-Virtual Machine (b) Virtual Machine

51
Virtualization Implementation
 Difficult to implement – must provide an
exact duplicate of underlying machine
 Typically runs in actual user mode,
 Creates Virtual User Mode and Virtual
Kernel Mode
 Timing can be an issue
 VM is slower than real machine
 Hardware support needed
 More HW support results better virtualization

52
VMware Architecture

53
The Java Virtual Machine (JVM)

54
Debugging Support
 Debugging is finding and fixing errors or
bugs
 OSes 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
 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.”
55
System Boot
 Operating system must be made available
to hardware so that hardware can start it
 Small piece of code – bootstrap loader,
locates the kernel, loads it into memory, and
starts it
 Sometimes two-step process where boot block
at fixed location loads bootstrap loader
 When power initialized on system, execution
starts at a fixed memory location
 Firmware used to hold initial boot code

56