0% found this document useful (0 votes)
20 views57 pages

OS Module1 Unit2

Uploaded by

padmakarnick
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)
20 views57 pages

OS Module1 Unit2

Uploaded by

padmakarnick
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/ 57

Study Material

Department of AIML
Semester /
Course Code : BCS303 III / II
Year :
Academic
Course Title : Operating Systems 2024-25
Year :
Module 1

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; Operating System
debugging, Operating System generation; System boot.

2
Operating System Services
 Operating Systems Interface
 System Calls
 Types of System Calls
 System Programs
 Operating-System Design and Implementation
 OS Structure
 Virtual Machine
 OS Debugging
 System Boot

3
Operating System Services
Operating System Services

 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).
 Varies
between Command-Line (CLI), Graphics User Interface (GUI),
Batch interface
 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)
 I/O operations - A running program may require I/O, which may involve a
file or an I/O device
Operating System Services (Cont.)
 One set of operating-system services provides functions that are helpful to
the user (Cont.):

 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.
 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 (packets moved by the OS)
Operating System Services (Cont.)
 Error detection – OS needs to be constantly aware of possible errors
 Mayoccur in the CPU and memory hardware, in I/O devices, in user
program
 Foreach type of error, OS should take the appropriate action to ensure
correct and consistent computing
 Debugging facilities can greatly enhance the user’s and programmer’s
abilities to efficiently use the system
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 - CPU cycles, main memory, file storage,
I/O devices.
 Accounting - To keep track of which users use how much and what
kinds of computer resources
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
A View of Operating System Services
User Operating System
Interface
User Operating System Interface - CLI

CLI or command interpreter allows direct command entry.


Some operating systems include the command interpreter in the kernel. Others treat the command
interpreter as a special program that is running when a job is initiated or when a user first logs
on.
On systems with multiple command interpreters to choose from, the interpreters are known as
shells.
The main function of the command interpreter is to get and execute the next user-specified
command.
These commands can be implemented in two general ways.
In one approach, the command interpreter itself contains the code to execute the command. In this
case, the number of commands that can be given determines the size of the command
interpreter, since each command requires its own implementing code.
An alternative approach implements most commands through system programs. In this case, the
command interpreter does not understand the command in any way; it merely uses the command
to identify a file to be loaded into memory and executed.
Bourne Shell Command Interpreter
User Operating System Interface - GUI

 User-friendly desktop metaphor interface


 Usually 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
(known as a folder)
 Invented at Xerox PARC (Research and Development Company)
User Operating System Interface - GUI
 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- Common
Desktop Environment (CDE) , K-Desktop Environment(KDE), GNU
Network Object Model Environment (GNOME)
Touchscreen Interfaces
 Touchscreen devices require new
interfaces
 Mouse not possible or not desired
 Actions and selection based on
gestures
 Virtual keyboard for text entry
 Voice commands.
System Calls

 Programming interface to the services provided by the OS


 These calls are generally available as routines written in C and C++,
although certain low-level tasks (for example, tasks where hardware
must be accessed directly), may need to be written using assembly-
language instructions.
System Calls

 How system calls are used: writing a simple program to read data from one file and copy
them to another file.
 The first input that the program will need is the names of the two files: the input file and the
output file. This sequence requires many I/0 system calls.
 Once the two file names are obtained, the program must open the input file and create the
output file. Each of these operations requires another system call.
 There are also possible error conditions for each operation. In these cases, the program
should print a message on the console (another sequence of system calls) and then terminate
abnormally (another system call).
 If the input file exists, then we must create a new output file. We may find that there is
already an output file with the same name. This situation may cause the program to abort (a
system call), or we may delete the existing file (another system call) and create a new one
(another system call).
System Calls

 Now that both files are set up, we enter a loop that reads from the input file (a system call)
and writes to the output file (another system call). Each read and write must return status
information regarding various possible error conditions.
 On input, the program may find that the end of the file has been reached or that there was a
hardware failure in the read (such as a parity error).
 The write operation may encounter various errors, depending on the output device (no more
disk space, printer out of paper, and so on).
 Finally, after the entire file is copied, the program may close both files (another system
call), write a message to the console or window (more system calls), and finally terminate
normally (the final system call).
System Calls

Application developers design programs according to an Application Programming Interface.


The API specifies a set of functions application programmer/ including the parameters that are
passed to each function and the return values the programmer can expect.
Three of the most common APis available to application programmers are the Win32 API for
Windows systems, the POSIX API for POSIX-based systems (which include virtually all
versions of UNIX, Linux/ and Mac OS X), and the Java API for designing programs that
run on the Java virtual machine.
Behind the scenes/ the functions that make up an API typically invoke the actual system calls
on behalf of the application programmer.
Example of System Calls
 System call sequence to copy the contents of one file to another file
API – System Call – OS Relationship
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
 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
Types of System Calls
 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
Types of System Calls
 Protection
 Control access to resources
 Get and set permissions
 Allow and deny user access
Examples of Windows and UNIX System
Calls
System Programs
 System programs provide a convenient environment for program
development and execution. 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
 Most users’ view of the operating system is defined by system programs,
not the actual system calls
System Programs
 Provide a convenient environment for program development and execution
 Some of them are simply user interfaces to system calls; others are
considerably more complex

 File management - Create, delete, copy, rename, print, 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
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 sometimes provided
 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
System Programs (Cont.)
 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
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

 User goals and System goals


 User goals – operating system should be convenient to use, easy to
learn, reliable, safe, and fast
 System goals – operating system should be easy to design, implement,
and maintain, as well as flexible, reliable, error-free, and efficient
Operating System Design and
Implementation (Cont.)
 Important principle to separate
Policy: What will be done?
Mechanism: How to do it?
 Mechanisms determine how to do something, policies decide what will
be done
 The separation of policy from mechanism is a very important principle,
it allows maximum flexibility if policy decisions are to be changed later
(example – timer)
 Specifying and designing an OS is highly creative task of software
engineering
Implementation
 Much variation
 Early OSes in assembly language
 Then system programming languages like Algol, PL/1
 Now C, C++
 Actually 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
 More high-level language easier to port to other hardware
 But slower
 Emulation can allow an OS to run on non-native hardware
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
 Most commercial OS do not have well
defined structure ,frequently such
system started as simple ,small and
limited system
 MS-DOS – was originally designed
and implemented by few engineers
without having an idea that it will
become so popular
 MS-DOS – written to provide the most
functionality in the least space
 Not divided into modules
Simple Structure -- MS-DOS
 Although MS-DOS has some
structure, its interfaces and levels
of functionality are not well
separated
 Application program able to access
basic I/O routines to write directly
to display or disk drive such
freedom leaves MSDOS
vulnerable to errant programs
causing entire system to crash
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 series of interfaces and physical hardware which
can be added and expanded over the years as UNIX has
evolved over the years
 Providesthe file system, CPU scheduling, memory
management, and other operating-system functions; a large
number of functions for one level
Traditional UNIX System Structure
Fig shows everything below system call interfaces and device drivers
Layered Approach
 The operating system can be
broken into pieces that are smaller
and more appropriate than allowed
by the original MS-DOS and UNIX
system.
 It retains much greater control over
the computer and over the
applications that make use of that
computer.
 One approach is layered approach
in which 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.
Layered Approach
 An operating system layer is an
implementation of an abstract object
made up of data and operations that
can manipulate those data.
 A typical operating system layer Layer
M consists of data structures and set
of routines that can be invoked by
higher level layers
 With modularity,higher level layers
uses functions (operations) and
services of only lower-level layers
Microkernel System Structure
 As UNIX expanded ,the kernel become large and difficult to
manage
 Melon university developed an operating system Mach that
modularized the kernel using Microkernel Approach
 This method structures the operating system by removing all
non-essential components from the kernel and implementing
them as system and user level programs resulting smaller kernel
 Function of microkernel is to provide communication facility
between the client program and services that also running in user
space
 Communication takes place between user modules using
message passing
Microkernel System Structure
Microkernel System Structure
 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
 Demerits:
 Performance overhead of user space to kernel space
communication
Modules
 The best current methodology for operating-system design involves using object-oriented programming
techniques to create a modular kernel.
 Here, the kernel has a set of core components and links in additional services either during boot time or
during run time.
 Such a strategy uses dynamically loadable modules and is common in modern implementations of UNIX,
such as Solaris, Linux, and Mac OS X.
 Such a design allows the kernel to provide core services yet also allows certain features to be implemented
dynamically.
 The overall result resembles a layered system in that each kernel section has defined, protected interfaces;
but it is more flexible than a layered system in that any module can call any other module.
 Furthermore, the approach is like 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.
Modules
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.”
Operating-System Debugging
 Operating system debugging is the process of identifying and fixing errors or bugs in an operating system.
Debugging is a crucial step in the development and maintenance of an operating system, as it ensures that
the system is stable, secure, and functions as intended.
 Types of Debugging:
 Kernel Debugging: Kernel debugging involves identifying and fixing errors in the kernel, which is the
core part of the operating system.
 Device Driver Debugging: Device driver debugging involves identifying and fixing errors in device
drivers, which are software components that manage hardware devices.
 System Call Debugging: System call debugging involves identifying and fixing errors in system calls,
which are interfaces between the operating system and applications.
 Memory Debugging: Memory debugging involves identifying and fixing errors related to memory
management, such as memory leaks or corruption.
Operating-System Debugging
 Debugging Tools:
 Print Statements: Print statements are used to print debug messages to the console or a log file.
 Debuggers: Debuggers are software tools that allow developers to step through code, set breakpoints,
and examine variables.
 System Calls Tracing: System calls tracing involves tracing system calls to identify errors or
performance issues.
 Memory Profilers: Memory profilers are tools that analyze memory usage and identify memory leaks
or corruption.
 Debugging Techniques:
 Divide and Conquer: Divide and conquer involves dividing the code into smaller sections and
debugging each section separately.
 Print and Analyze: Print and analyze involves printing debug messages and analyzing the output to
identify errors.
 Use of Debugging Tools: Use of debugging tools involves using tools such as debuggers and memory
profilers to identify and fix errors.
 Code Review: Code review involves reviewing code to identify errors or potential issues.
Operating-System Debugging
 Common Operating System Debugging Issues:
 Deadlocks: Deadlocks occur when two or more processes are blocked, waiting for each other to
release resources.
 Starvation: Starvation occurs when a process is unable to access resources due to other processes
holding onto them for an extended period.
 Livelocks: Livelocks occur when two or more processes are unable to proceed due to constant retries.
 Memory Leaks: Memory leaks occur when memory is allocated but not released, leading to memory
exhaustion.
 Best Practices for Operating System Debugging:
 Use Debugging Tools: Use debugging tools to identify and fix errors.
 Write Clean Code: Write clean, modular, and well-documented code to reduce errors.
 Test Thoroughly: Test the operating system thoroughly to identify errors.
 Code Review: Perform regular code reviews to identify errors or potential issues.
Operating System Generation
 Design ,code and implement an operating system specifically for
one machine at one site.
 Operating systems are designed to run on any of a class of
machines at a variety of sites with variety of peripheral
configurations
 The system must be configured or generated
for each specific
computer site, a process known as System Generation
(SYSGEN)
 The operating system is distributed on Disk ,on CD-ROM,DVD-
ROM or as an ISO image, which is a file in the format of CD-ROM
or DVD-ROM
 To generate a system , special program is used
Operating System Generation
 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

 Following kinds of information must be determined


 What CPU to be used ? Multiprocessor system
 How will the boot disk be formatted ? How many sections or
partitions and what information will go to which partitions
 How much memory is available ? Some systems determine this
value themselves by referencing memory locations untill an illegal
address fault is generated .It determine final legal address and
hence amount of memory available
Operating System Generation
 What devices are available ? The system need to know to
address each device ,the device interrupt number ,the device’s
type and model ,and any special device characteristics.
 What operating system options are desired or what parameter
values are used. These options or values might include how many
buffers of which sizes should be used ,what type of CPU-
scheduling algorithm is desired ,what the maximum of processes
to be supported
System Boot
 When power initialized on system, execution starts at a fixed memory
location
 Firmware ROM used to hold initial boot code
 Operating system must be made available to hardware so hardware can
start it
 Small piece of code – bootstrap loader, stored in ROM or EEPROM
locates the kernel, loads it into memory, and starts it
 Sometimes two-step process where boot block at fixed location loaded
by ROM code, which loads bootstrap loader from disk
 Common bootstrap loader, GRUB, allows selection of kernel from multiple
disks, versions, kernel options
 Kernel loads and system is then running
System Boot
 System Boot Process:
 The system boot process, also known as booting, is the process by which a computer system
starts up and loads its operating system and other essential software. The boot process involves a
series of steps that occur in a specific order, and it is a critical part of the system's initialization.
 Steps in the System Boot Process:
 Power-On Self-Test (POST): When the power button is pressed, the system's power supply unit
(PSU) sends power to the motherboard, and the system begins to boot. The POST checks the
system's hardware components, such as the CPU, memory, and storage devices, to ensure they
are functioning properly.
 Bootloader: The bootloader is a small program that is stored in the system's firmware, typically
in the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface). The
bootloader is responsible for loading the operating system into memory.
 Boot Device Selection: The bootloader searches for a boot device, such as a hard drive, solid-
state drive (SSD), or USB drive, that contains the operating system. The bootloader checks the
boot device's partition table to determine which partition contains the operating system.
 Operating System Loading: The bootloader loads the operating system into memory, starting
with the kernel. The kernel is the core part of the operating system that manages the system's
hardware resources and provides services to applications.
System Boot
 Device Initialization: The operating system initializes the system's hardware devices, such as the
keyboard, mouse, and network interface card.
 System Services: The operating system starts system services, such as the file system, network
services, and security services.
 User Space: The operating system creates a user space, which is the environment in which
applications run. The user space includes the shell, which is the command-line interface to the
operating system.
 Login: The system prompts the user to log in, and the user enters their credentials. The operating
system authenticates the user and grants access to the system.
 Types of Boot Processes:
 Cold Boot: A cold boot occurs when the system is powered on from a completely powered-off
state.
 Warm Boot: A warm boot occurs when the system is restarted from a running state, such as when
the user clicks the restart button.
 Soft Boot: A soft boot occurs when the system is restarted without powering off, such as when
the user closes the lid of a laptop.
System Boot
 Boot Process Variations:
 UEFI Boot: UEFI boot is a type of boot process that uses the UEFI firmware instead of the
traditional BIOS.
 Secure Boot: Secure boot is a type of boot process that ensures the system boots only with
authorized software.
 Network Boot: Network boot is a type of boot process that loads the operating system from a
network location instead of a local device.

You might also like