System Calls


The Linux kernel has three fundamental responsibilities: to control processes, to manage the filesystem, and to operate peripheral devices. As a programmer you have access to these kernel operations through system calls and library functions. This section discusses system calls at a general level; a detailed treatment is beyond the scope of this book.

As the name implies, a system call instructs the system (kernel) to perform some work directly on your behalf. The request tells the kernel what work needs to be done and includes the necessary arguments. For example, a system call to open a file includes the name of the file. A library routine is less direct: It issues system calls on your behalf. The advantages of a library routine are that it may insulate you from the low-level details of kernel operations and that it has been written carefully to make sure that it performs efficiently.

For example, it is straightforward to use the standard I/O library function fprintf() to send text to standard output or standard error. Without this function, you would need to issue several system calls to achieve the same result. The calls to the library routines putchar() and getchar() in Figure 27-1 on page 834 ultimately use the write() and read() system calls to perform the I/O operations.

strace: Traces System Calls

The strace utility is a debugging tool that displays a trace of all system calls made by a process or program. Because you do not need to recompile the program that you want to trace, you can use strace on binaries that you do not have source for.

System calls are events that take place at the interface (boundary) between user code and kernel code. Examining this boundary can help you isolate bugs, track down race conditions, and perform sanity checking. For more information refer to the strace home page (www.liacs.nl/~wichert/strace and sourceforge.net/projects/strace.)

Controlling Processes

When you enter a command at a shell prompt, the shell process calls the fork() system call to create a copy of itself (spawn a child) and then uses an exec() system call to overlay that copy in memory with a different program (the command you asked it to run). Table 27-3 lists system calls that affect processes.

Table 27-3. System calls: process control

System call

Function

fork()

Creates a copy of a process

exec()

Overlays a program in memory with another program

getpid()

Returns the PID number of the calling process

getppid()

Returns the PID number of the calling process's parent process

wait()

Causes the parent process to wait for the child process to finish running before it resumes execution

exit()

Causes a process to exit

nice()

Changes the priority of a process

kill()

Sends a signal to a process


Accessing the Filesystem

Many operations take place when a program reads from or writes to a file. Because the program needs to know where the file is located, the filename must be converted to an inode number on the correct filesystem. Your access permissions must be checked not only for the file itself but also for all intervening directories in the path to the file. Because the file is not stored in one continuous piece on the disk, all disk blocks that contain pieces of the file must be located. The appropriate kernel device driver must be called to control the operation of the disk. Once the file has been found, the program may need to find a particular location within the file rather than working with it sequentially from beginning to end. Table 27-4 lists some of the most common system calls for filesystem operations.

Table 27-4. System calls: filesystem

System call

Function

stat()

Gets status information from an inode, such as the inode number, the device on which it is located, owner and group information, and the size of the file

lseek()

Moves to a position in the file

creat()

Creates a new file

open()

Opens an existing file

read()

Reads a file

write()

Writes a file

close()

Closes a file

unlink()

Unlinks a file (deletes a name reference to the inode)

chmod()

Changes file access permissions

chown()

Changes file ownership


Access to peripheral devices on a Linux system is handled through the filesystem interface. Peripheral devices are represented by one or more special files, usually located under /dev. When you read from or write to one of these special files, the kernel passes your request to the appropriate kernel device driver. As a result you can use the standard system calls and library routines to interact with these devices; you do not need to learn a new set of specialized functions. This ability is one of the most powerful features of a Linux system because it allows users to use the same basic utilities on a wide range of devices.

The availability of standard system calls and library routines is the key to the portability of Linux tools. For example, as an applications programmer, you can rely on the read() and write() system calls working the same way on different versions of the Linux system and on different types of computers. The systems programmer who writes a device driver or ports the kernel to run on a new computer, however, must understand the details at their lowest level.




A Practical Guide to Red Hat Linux
A Practical Guide to Red HatВ® LinuxВ®: Fedoraв„ў Core and Red Hat Enterprise Linux (3rd Edition)
ISBN: 0132280272
EAN: 2147483647
Year: 2006
Pages: 383

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net