Linux Kernel Architecture

Chapter 1: Introduction and Overview

1.3.7 System Calls

System callsare the classical method of enabling user processes to interact with the kernel. The POSIX

standard defines a number of system calls and theireffect as implemented on all POSIX-compliant sys-

tems including Linux. Traditional system calls are grouped into various categories:

❑ Process Management— Creating new tasks, querying information, debugging

❑ Signals— Sending signals, timers, handling mechanisms

❑ Files— Creating, opening, and closing files, reading from and writing to files, querying infor-

mation and status

❑ Directories and Filesystem— Creating, deleting, and renaming directories, querying informa-

tion, links, changing directories

❑ Protection Mechanisms— Reading and changing UIDs/GIDs, and namespace handling

❑ Timer Functions— Timer functions and statistical information

Demands are placed on the kernel in all these functions. They cannot be implemented in a normal user

library because special protection mechanisms are needed to ensure that system stability and/or security

are not endangered. In addition, many calls are reliant on kernel-internal structures or functions to yield

desired data or results — this also dictates against implementation in userspace. When a system call is

issued, the processor must change the privilege level and switch from user mode to system mode. There

is no standardized way of doing this in Linux as each hardware platform offers specific mechanisms.

In some cases, different approaches are implemented on the same architecture but depend on processor

type. Whereas Linux uses a special software interrupt to execute system calls on IA-32 processors, the

software emulation (iBCS emulator) of otherUnixsystems on IA-32 employs a different method to

execute binary programs (for assembly language aficionados: thelcall7orlcall27gate). Modern

variants of IA-32 also have their own assembly language statement for executing system calls; this was

not available on old systems and cannot therefore beused on all machines. What all variants have in

common is that system calls are the only way of enabling user processes to switch in their own incentive

from user mode to kernel mode in order to delegate system-critical tasks.

1.3.8 Device Drivers, Block and Character Devices

The role of device drivers is to communicate with I/O devices attached to the system; for example, hard

disks, floppies, interfaces, sound cards, and so on. In accordance with the classicalUnixmaxim that

‘‘everything is a file,’’ access is performed using device files that usually reside in the/devdirectory and

can be processed by programs in the same way as regular files. The task of a device driver is to support

application communication via device files; in other words, to enable data to be read from and written to

a device in a suitable way.

Peripheral devices belong to one of the following two groups:

1. Character Devices— Deliver a continuous stream of data that applications read sequen-
   tially; generally, random access is not possible. Instead, such devices allow data to be read
   and written byte-by-byte or character-by-character. Modems are classical examples of char-
   acter devices.