Chapter 3 : UNIX System calls

and Error Handling

1
 Introduction

• System programs interact with the OS (and

ultimately hardware) through system calls.

• They are called when a user level program needs a

service from the OS.
• Generally written in C/C++

• Execute in kernel mode – code can access protected

hardware.

2
Kernel

• Kernel is a program that is loaded from disk into

RAM when the computer is first tuned on.
• Kernel always stay in RAM and runs until the system
is turned off or crashes.
• Kernel Subsystems
 Memory management
 Process management
 Interprocess communication(IPC)
 Input/output
 File management 3
Unix Kernel

• Part of the UNIX operating system that contains the

code for:
• sharing the CPU and RAM between competing
processes
• processing all system calls
• handling peripherals

4
 OS Services

• Application programs communicate with

the operating system in order to make use
of services such as:
• file creation
• process duplication, and
• interprocess communication (IPC)

5
 System Calls

• Definitions
• A request to the operating system to perform some
activity
• Well-defined entry point into kernel to request a service
• Collection of routines which are programmer’s functional
interface to the UNIX kernel.
• System calls are just like library routines, except that they
perform a subroutine call directly into the heart of UNIX.
• User programs make use of the kernel via the system call
interface

6
 Executing a System Call

• The system needs to perform many things

before executing a system call
• The computer (hardware) saves its state
• The OS code takes control of the CPU, privileges
are updated.
• The OS examines the call parameters
• The OS performs the requested function
• The OS saves its state (and call results)
• The OS returns control of the CPU to the caller 7
System calls Vs Function calls

8
System calls vs Library calls

9
 System and Library Calls

The following are system calls and library calls in UNIX,

listed in alphabetical order:
accept getdents nice
alarm getegid ntohl
bind geteuid ntohs
bzero getgid open
chdir gethostname pause
chmod gethostbyname perror
chown getpgid pipe
close getpid read
connect getppid setegid
dup getuid seteuid
dup2 htonl setgid
10
 System and Library Calls (cont’d)

execl htons setpgid

execlp inet_addr setuid
execv inet_ntoa signal
execvp ioctl socket
exit kill stat
fchmod lchown sync
fchown link truncate
fcntl listen unlink
fork lseek wait
fstat lstat write
ftruncate memset
mknod mknod
11
 System and Library Calls (cont’d)

• UNIX system calls can be loosely grouped into the

following categories:
• Process management
• File management
• Device management
• Information maintenance
• Communications
• Message passing
• Shared memory
• Protection
• Error handling 12
 File Management System calls hierarchy

Files

open close read write lseek unlink chown dup2 special Directory

chmod fcntl fstat ftruncate truncate stat sync dup link

mknod ioctl pipe Sockets getdents

Internet sockets accept bind connect listen socket

gethostbyname gethostname htonl htons inet_addr inet_ntoa

13
Process Management System call hierarchy

Process management

nice chdir wait fork exec exit Signals

setgid setpgrp getpgrp getppid setuid

getgid getrgid getuid getruid

alarm signal kill pause

14
Error-Handling hierarchy

Error handling

perror

15
System calls summary

• Error Handling:
• perror()
• Regular file management:
• how to create, open, close, read, and write
regular files.
• Process management:
• how to duplicate, differentiate, suspend, and
terminate processes and briefly discusses
multithreaded processes.
16
System calls summary

• Interprocess Communication (IPC):

• describes interprocess communication via
pipes (both unnamed pipes and named pipes)
and sockets (including information about
Internet sockets)
• Signals:
• the signal facility could come under the
heading of either process management or

interprocess communication.
17
Application Programming Interface

• In ordinary programming, application code

generally does not invoke system calls directly.
• Programmer calls functions defined by an API.
• Win32 API (Windows OSs)
• POSIX API (Most Unix-like OS's)

• API - Basically a bunch of C header files along

with precise, legalistic, descriptions of functionality.

18
UNIX API Invocation Example

19
Win32 API Example

• 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
20
Why use an API?

• API tends to be more programmer friendly than

direct system calls.
• Designing an OS involves trade-offs between
ease of use, and ease of implementation.
• System calls – driven by ease of implementation
• API – driven by ease of use.

• Some API calls are basically wrappers for

system calls.
• Some are much more complex.
• Coding to an API results in more portable code. 21
APIs and System calls

• An API does not necessarily correspond to a

specific system call.
• First of all, the API could offer its services directly
in user mode. (For something abstract such as math
functions, there may be no reason to make system
calls.)
• Second, a single API function could make several
system calls.
• Moreover, several API functions could make the
same system call, but wrap extra functionality
around it. 22
Example - Different APIs using same
system call
• In Linux, the malloc(), calloc(), and free() APIs
are implemented in the libc library.
• The code in this library keeps track of the
allocation and deallocation requests and uses
the brk() system call to enlarge or shrink the
process heap.

23
Error Handling

24
System calls summary

• All system calls return -1 if an error occurs

• There are a number of helpful facilities to diagnose
the problem
• errno - a global variable that holds the numerical
code of the last system call error
• perror() - a subroutine that describes system call
errors.
• strerror() - library routine

25
Error Handling: errno

• Every process contains a global variable called errno, that is

originally set to zero when the process is created.
• A successful system call never affects the current value of “errno” and
unsuccessful system call always overwrites the current value of
“errno”.
• To access “errno” from your program, include “errno.h”.
• The file “/usr/include/sys/errno.h” contains a list of the predefined error
codes, including:
#define EPERM 1 /* No owner */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINSR 4 /* Interrupted System call */
#define EIO 5 /* I/O error */ 26
Error Handling: perror()

• Library routine (stdio.h)

• Syntax:
Library Routine: void perror(char* str)
• perror() displays the string str, followed by colon,
followed by a description of the last system call
error.
• If there is no error to report, it displays the string
“Error 0”.
• Actually, “perror()” isn’t a system call - it’s a
standard C library routine. 27
Error Handling: perror()

• A system call may fail due to several different

reasons.
• Systems Programming Pattern:
• Make a system call, then
• Check system calls for return values of -1 (error
indication)
• Use errno to determine and respond to the cause of the
error.
• Call perror() or strerror() for an error description during
debugging 28
Program Example

$ showErrno.c
#include <stdio.h>
#include <sys/file.h>
#include <errno.h>
main(){
int fd;
/* Open a nonexistent file to cause an error */
fd = open(“nonexist.txt”, O_RDONLY);
if ( fd==-1 ) /* fd == -1 , an error occurred */
{
printf( “errno = %d \n”, errno );
perror(“main”);
}
fd=open( “/”, O_WRONLY ); /* Force a different error */
if ( fd== -1 )
{ printf(“errno=%d\n”, errno);
perror(“main”); } 29
Error Handling: perror()

/* Execute a successful system call */

fd = open(“nonexist.txt”, O_RDONLY | O_CREAT, 0644 );
printf(“errno=%d\n”, errno); /* Display after successful call */
perror(“main”);
errno=0; /* Manually reset error variable */
perror(“main”);
}
Here’s the output from this program:
$ showErrno ---> run the program.
errno=2
main: No such file or directory
errno=21 ---> even after a successful call.0
main: Is a directory
errno=21
main: Is a directory
main: Error 0
$_ 30
Error Handling: strerror()

• Library routine (string.h)

• Syntax:
char* strerror (int errcode)
• strerror() takes an integer argument (errno) and returns
a string that specifies the error message
• Use strerror() instead of perror() when you care about
output formatting

31