SYSTEM CALLS by bH1nxDE0

VIEWS: 0 PAGES: 10

									        SYSTEM CALLS IN OPERATING SYSTEMS
Kernel:
     Kernel is the core of the operating system and it
facilitates the user programs by managing the hardware
resources. Kernel provides a simple interface to the
application programs to interact with the hardware and that
interface is provided in the form of system calls.




Privileged Mode:
   Special Instructions
   Mapping, TLB, etc
   Device registers
   I/O channels, etc.
   Mode Bits
   Processor features
   Device access

What are System Calls?
     When a computer is turned on, the program that gets
executed first is called the “operating system”. It controls
pretty much all activity in the computer. This includes who
logs in, how disks are used, how memory is used, how the CPU
is used, and how you talk with other computers. The
operating system we use is called "Unix".The way that
programs talk to the operating system is via ``system
calls.''
     A system call looks like a procedure call but it's
different -- it is a request to the operating system to
perform some activity. System calls are functions that a
programmer can call to perform the services of the operating
system.
     In computing, a system call is how a program requests a
service from an operating system's kernel. This may include
hardware related services (e.g. accessing the hard disk),
creating and executing new processes, and communicating with
integral kernel services (like scheduling). System calls
provide the interface between a process and the operating
system.
     A system call is just what its name implies -- a
request for the operating system to do something on behalf
of the user's program. The system calls are functions used
in the kernel itself. To the programmer, the system call
appears as a normal C function call.

Classification:
     System calls can be roughly grouped into five major
categories: process control, file management, device
management, information maintenance and communication.

1. 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;

2. File management:
   Create file, delete file
   open, close, read, write, reposition
   get file attributes, set file attributes
   Commit data to disk

3. Device management:
   Request device, release device
   read, write, reposition
   get device attributes, set device attributes
   Logically attach or detach devices

4. Information maintenance:
   Get time or date, set time or date
   get system data, set system data
   get process, file, or device attributes
   set process, file, or device attributes

5. Communications:
   Create, delete communication connection
   send, receive messages, transfer status information
   Attach or detach remote devices

System Call Mechanism:
   User code can be arbitrary
   User code cannot modify kernel memory
   Makes a system call with parameters
   The call mechanism switches code to kernel mode
   Execute system call
   Return with results

Execution of a System Call:
     Each system call has its own unique identifying number.
The kernel uses this number as an index into a table of
system call entry points, which point to where the system
calls reside in memory along with the number of arguments
that should be passed to them.
     When a process makes a system call, the behavior is
similar to that of interrupts and exceptions. Like exception
handling, the general purpose registers and the number of
the system call are pushed onto the stack. Next, the system
call handler is invoked, which calls the routine within the
kernel that will do the actual work.
     Although there are hundreds of library calls, each of
these will call one or more systems calls. In total, there
are about 150 system calls, all of which have to pass
through this one point (referred to as a "call gate") to
ensure that user code moves up to the higher privilege level
at a specific location (address)within the kernel.
Therefore, uniform controls can be applied to ensure that a
process is not doing something it shouldn't.
     As with interrupts and exceptions, the system checks to
see whether a context switch should occur on return to user
mode. If so, a context switch takes place. This is possible
in situations where one process made a system call and an
interrupt occurred while the process was in kernel mode. The
kernel then issued a wake_up() to all processes waiting for
data from the hard disk.
     When the interrupt completes, the kernel may go back to
the first process that made the system call.

     The library routines execute in user mode, but the
system call interface is a special case of an interrupt
handler. The library functions pass the kernel a unique
number per system call in a machine dependent way either as
a parameter to the operating system trap, in a particular
register, or on the stack -- and the kernel thus determines
the specific system call the user is invoking. In handling
the operating system trap, the kernel looks up the system
call number in a table to find the address of the
appropriate kernel routine that is the entry point for the
system call and to find the number of parameters the system
call expects. The kernel calculates the (user) address of
the first parameter to the system call by adding (or
subtracting, depending on the direction of stack growth) an
offset to the user stack pointer, corresponding to the
number of the parameters to the system call.
     Finally, it copies the user parameters to the "u area"
and call the appropriate system call routine. After
executing the code for the system call, the kernel
determines whether there was an error. If so, it adjusts
register locations in the saved user register context,
typically setting the "carry" bit for the PS (processor
status) register and copying the error number into register
0 location. If there were no errors in the execution of the
system call, the kernel clears the "carry" bit in the PS
register and copies the appropriate return values from the
system call into the locations for registers 0 and 1 in the
saved user register context. When the kernel returns from
the operating system trap to user mode, it returns to the
library instruction after the trap instruction. The library
interprets the return values from the kernel and returns a
value to the user program.




Understanding a System Call Execution:
     A system call is implemented by a ``software
interrupt'' that transfers control to kernel code; in
Linux/i386 this is ``interrupt 0x80''. The specific system
call being invoked is stored in the EAX register, and its
arguments are held in the other processor registers.
     After the switch to kernel mode, the processor must
save all of its registers and dispatch execution to the
proper kernel function, after checking whether EAX is out of
range. The system call we are looking at is implemented in
the sys_read function, and it must (like several other
system call) dispatch execution to a file object. The file
object itself must first be looked up based on the file
descriptor that the user application passed to the system
call. The read method for the file object finally performs
the data transfer and all the previous steps are unwound up
to the calling user function.
     System calls provide an interface between the process
and the operating system. System calls allow user-level
processes to request some services from the operating system
which process itself is not allowed to do. In handling the
trap, the operating system will enter in the kernel mode,
where it has access to privileged instructions, and can
perform the desired service on the behalf of user-level
process. It is because of the critical nature of operations
that the operating system itself does them every time they
are needed. For example, for I/O a process involves a system
call telling the operating system to read or write
particular area and this request is satisfied by the
operating system.
     System programs provide basic functioning to users so
that they do not need to write their own environment for
program development (editors, compilers) and program
execution (shells). In some sense, they are bundles of
useful system calls.

Library Functions:
     Most languages provide library functions to provide
theses functionalities and these library functions in turn
use system calls. For example, fread() and fwrite are the
library functions that are equivalent to the 'read' and
'write' system calls in the Unix environment
     Whenever a program invokes a system call, it is
interrupted and some information is saved that is used for
restoring the program. CPU then starts executing in the
kernel mode and a routine corresponding to the system call
is executed. After the completion of that routine the
control is transferred to the user mode and the program is
restored.
     Generally, systems provide a library or API that sits
between normal programs and the operating system, usually an
implementation of the C library (libc), such as glibc, that
provides wrapper functions for the system calls, often named
the same as the system calls that they call. The library's
wrapper functions expose an ordinary function calling
convention (a subroutine call on the assembly level) for
using the system call, as well as making the use of the
system call more modular. Here, the primary function of the
wrapper is to place all the arguments to be passed to the
system call, and also setting a unique system call number
for the kernel to call. In this way the library, which
exists between the OS and the application, increases
portability.
     The call to the library function itself does not cause
a switch to kernel mode (if the execution was not already in
kernel mode) and is usually a normal subroutine call (i.e.
using a "CALL" assembly instruction in some ISAs). The
actual system call does transfer control to the kernel (and
is more implementation-dependent and platform-dependent than
the library call abstracting it). For example, in Unix-like
systems, "fork" and "execve" are C library functions that in
turn execute instructions that invoke the "fork" and
"execve" system calls. Making the system call directly in
the application code is more complicated and may require
embedded assembly code to be used (in C and C++) as well as
knowledge of the application binary interface; the library
functions are meant to abstract this away.

Security using System Calls:
     The design of the microprocessor architecture on
practically all modern systems (except some embedded
systems) involves a security model (such as the rings model)
which specifies multiple privilege levels under which
software may be executed; for instance, a program is usually
limited to its own address space so that it cannot access or
modify other running programs or the operating system
itself, and a program is usually prevented from directly
manipulating hardware devices (e.g. the frame buffer or
network devices).
     However, many normal applications obviously need access
to these components, so system calls are made available by
the operating system to provide well-defined, safe
implementations for such operations. The operating system
executes at the highest level of privilege, and allows
applications to request services via system calls, which are
often executed via interrupts; an interrupt automatically
puts the CPU into some required privilege level, and then
passes control to the kernel, which determines whether the
calling program should be granted the requested service. If
the service is granted, the kernel executes a specific set
of instructions over which the calling program has no direct
control, returns the privilege level to that of the calling
program, and then returns control to the calling program.
This concept also serves as a way to implement security.
Checking for Error:
     When a system call discovers and error, it returns -1
and stores the reason the called failed in an external
variable named "errno". The "/usr/include/errno.h" file
maps these error numbers to manifest constants, and it these
constants that you should use in your programs.
     When a system call returns successfully, it returns
something other than -1, but it does not clear "errno".
"errno" only has meaning directly after a system call that
returns an error.
     When you use system calls in your programs, you should
check the value returned by those system calls.
Furthermore, when a system call discovers an error, you
should use the "perror()" subroutine to print a diagnostic
message on the standard error file that describes why the
system call failed.

Some System Calls:
1. Open

    int open(const char *pathname, int flags, mode_t mode);

     Open makes a request to the operating system to use a
file. The 'path' argument specifies what file you would like
to use, and the 'flags' and 'mode' arguments specify how you
would like to use it. If the operating system approves your
request, it will return a ``file descriptor'' to you. This
is a non-negative integer. If it returns -1, then you have
been denied access, and you have to check the value of the
variable "errno" to determine why.
All actions that you will perform on files will be done
through the operating system. Whenever you want to do file
I/O, you specify the file by its file descriptor. Thus,
whenever you want to do file I/O on a specific file, you
must first open that file to get a file descriptor.

2. Close
     int close(int fd);

     Close() tells the operating system that you are done
with a file descriptor. The OS can then reuse that file
descriptor.
Any locks held on the file it was associated with, and owned
by the process, are removed.

3. Read

    int read(int fd, void *buf, int count);

     Read() tells the operating system to read "size" bytes
from the file opened in file descriptor "fd", and to put
those bytes into the location pointed to by "buf". It
returns how many bytes were actually read.

4. Write

    int write(int fd, void *buf, int count);

     Write() is just like read(), only it writes the bytes
instead of reading them. It returns the number of bytes
actually written, which is almost invariably "size".

5. Lseek
     All open files have a "file pointer" associated with
them. When the file is opened, the file pointer points to
the beginning of the file. As the file is read or written,
the file pointer moves. You can move the file pointer
manually with lseek().The return value is the offset of the
pointer after the lseek.

Context Switching:
     A system call is processed in kernel mode, which is
accomplished by changing the processor execution mode to a
more privileged one, but no process context switch is
necessary. The hardware sees the world in terms of the
execution mode according to the processor status register,
and processes are an abstraction provided by the operating
system. A system call does not require a context switch to
another process; it is processed in the context of whichever
process invoked it.
Advantages
   Simplicity
   Generality – same call handles many cases
   Composition / decomposition

Disadvantages
   System calls are expensive. While a procedure call can
     usually be performed in a few machine instructions, a
     system call requires the computer to save its state,
     let the operating system take control of the CPU, have
     the operating system perform some function, have the
     operating system save its state, and then have the
     operating system give control of the CPU back to you.
     This concept is important, and will be seen time and
     time again in this class.
   Performance
   To implement system call, one would need specialized
     knowledge of I/O registers, the sequence of operations
     needed to use them; and most important of all,
     implement enough protection because I/O resources are
     generally shared among multiple users and/or processes.


Library Benefits
   Call overhead
   Chains of alloc/free don’t go to kernel
   Flexibility – easy to change policy
   Fragmentation
   Coalescing, free list management
   Easier to program

Uses of System calls:
   The services provided by the operating system are
     allocation and deallocation of memory, reporting of
     current date and time etc. These services can be used
     by an application with the help of system calls.
   System calls are used whenever a program needs to
     access a restricted resource, eg a file on the hard
     disk, any hardware device, or when it needs to print or
     draw to the screen.
   System calls provide an interface to communicate with
     the operating system kernel.
   Basic system services such as accessing files and the
     communications amongst the processes are provided to
     the application programs via system calls.
Opening/Closing a file

								
To top