Kernel Modules Versus Applications

Before we go further, it’s worth underlining the various differences between a kernel
module and an application.
While most small and medium-sized applications perform a single task from beginning
to end, every kernel module just registers itself in order to serve future requests,
and its initialization function terminates immediately. In other words, the task of the
module’s initialization function is to prepare for later invocation of the module’s
functions; it’s as though the module were saying, “Here I am, and this is what I can
do.” The module’s exit function (hello_exit in the example)gets invoked just before
the module is unloaded. It should tell the kernel, “I’m not there anymore; don’t ask
me to do anything else.” This kind of approach to programming is similar to eventdriven
programming, but while not all applications are event-driven, each and every
kernel module is. Another major difference between event-driven applications and
kernel code is in the exit function: whereas an application that terminates can be lazy
in releasing resources or avoids clean up altogether, the exit function of a module
must carefully undo everything the init function built up, or the pieces remain
around until the system is rebooted.
Incidentally, the ability to unload a module is one of the features of modularization
that you’ll most appreciate, because it helps cut down development time; you can
test successive versions of your new driver without going through the lengthy shutdown/
reboot cycle each time.
As a programmer, you know that an application can call functions it doesn’t define:
the linking stage resolves external references using the appropriate library of functions.
printf is one of those callable functions and is defined in libc. A module, on the
other hand, is linked only to the kernel, and the only functions it can call are the
ones exported by the kernel; there are no libraries to link to. The printk function
used in hello.c earlier, for example, is the version of printf defined within the kernel
and exported to modules. It behaves similarly to the original function, with a few
minor differences, the main one being lack of floating-point support.

Thứ Bảy, 4 tháng 6, 2011 20:27 Đọc tiếp >>

Makefile

You can test the module with the insmod and rmmod utilities, as shown below. Note
that only the superuser can load and unload a module.
% make
make[1]: Entering directory `/usr/src/linux-2.6.10'
CC [M] /home/ldd3/src/misc-modules/hello.o
Building modules, stage 2.
MODPOST
CC /home/ldd3/src/misc-modules/hello.mod.o
LD [M] /home/ldd3/src/misc-modules/hello.ko
make[1]: Leaving directory `/usr/src/linux-2.6.10'
% su
root# insmod ./hello.ko
Hello, world
root# rmmod hello
Goodbye cruel world
root#
Please note once again that, for the above sequence of commands to work, you must
have a properly configured and built kernel tree in a place where the makefile is able
to find it (/usr/src/linux-2.6.10 in the example shown). We get into the details of how
modules are built in the section “Compiling and Loading.”
According to the mechanism your system uses to deliver the message lines, your output
may be different. In particular, the previous screen dump was taken from a text
console; if you are running insmod and rmmod from a terminal emulator running
under the window system, you won’t see anything on your screen. The message goes
to one of the system log files, such as /var/log/messages (the name of the actual file varies between Linux distributions).

Thứ Bảy, 4 tháng 6, 2011 20:26 Đọc tiếp >>

The Hello World Module

Many programming books begin with a “hello world” example as a way of showing
the simplest possible program. This book deals in kernel modules rather than programs;
so, for the impatient reader, the following code is a complete “hello world”
module:
#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("Dual BSD/GPL");
static int hello_init(void)
{
printk(KERN_ALERT "Hello, world\n");
return 0;
}
static void hello_exit(void)
{
printk(KERN_ALERT "Goodbye, cruel world\n");
}
module_init(hello_init);
module_exit(hello_exit);
This module defines two functions, one to be invoked when the module is loaded
into the kernel (hello_init)and one for when the module is removed (hello_exit). The
module_init and module_exit lines use special kernel macros to indicate the role of
these two functions. Another special macro (MODULE_LICENSE)is used to tell the
kernel that this module bears a free license; without such a declaration, the kernel
complains when the module is loaded.

Thứ Bảy, 4 tháng 6, 2011 20:25 Đọc tiếp >>

Classes of Devices and Modules

The Linux way of looking at devices distinguishes between three fundamental device
types. Each module usually implements one of these types, and thus is classifiable as a
char module, a block module, or a network module. This division of modules into different
types, or classes, is not a rigid one; the programmer can choose to build huge
modules implementing different drivers in a single chunk of code. Good programmers,
nonetheless, usually create a different module for each new functionality they
implement, because decomposition is a key element of scalability and extendability.

Thứ Bảy, 4 tháng 6, 2011 20:24 Đọc tiếp >>

Splitting the Kernel

In a Unix system, several concurrent processes attend to different tasks. Each process
asks for system resources, be it computing power, memory, network connectivity, or
some other resource. The kernel is the big chunk of executable code in charge of handling
all such requests. Although the distinction between the different kernel tasks
isn’t always clearly marked, the kernel’s role can be split (as shown in Figure 1-1)
into the following parts:
Process management
The kernel is in charge of creating and destroying processes and handling their
connection to the outside world (input and output). Communication among different
processes (through signals, pipes, or interprocess communication primitives)
is basic to the overall system functionality and is also handled by the
kernel. In addition, the scheduler, which controls how processes share the CPU,
is part of process management. More generally, the kernel’s process management
activity implements the abstraction of several processes on top of a single
CPU or a few of them.
Memory management
The computer’s memory is a major resource, and the policy used to deal with it
is a critical one for system performance. The kernel builds up a virtual addressing
space for any and all processes on top of the limited available resources. The
different parts of the kernel interact with the memory-management subsystem
through a set of function calls, ranging from the simple malloc/free pair to much
more complex functionalities.
Filesystems
Unix is heavily based on the filesystem concept; almost everything in Unix can
be treated as a file. The kernel builds a structured filesystem on top of unstructured
hardware, and the resulting file abstraction is heavily used throughout the
whole system. In addition, Linux supports multiple filesystem types, that is, different
ways of organizing data on the physical medium. For example, disks may
be formatted with the Linux-standard ext3 filesystem, the commonly used FAT
filesystem or several others.
Device control
Almost every system operation eventually maps to a physical device. With the
exception of the processor, memory, and a very few other entities, any and all
device control operations are performed by code that is specific to the device
being addressed. That code is called a device driver. The kernel must have
embedded in it a device driver for every peripheral present on a system, from the
hard drive to the keyboard and the tape drive. This aspect of the kernel’s functions
is our primary interest in this book.
Networking
Networking must be managed by the operating system, because most network
operations are not specific to a process: incoming packets are asynchronous
events. The packets must be collected, identified, and dispatched before a process
takes care of them. The system is in charge of delivering data packets across
program and network interfaces, and it must control the execution of programs
according to their network activity. Additionally, all the routing and address resolution
issues are implemented within the kernel.

Thứ Bảy, 4 tháng 6, 2011 20:20 Đọc tiếp >>

An Introduction to Device Drivers

One of the many advantages of free operating systems, as typified by Linux, is that
their internals are open for all to view. The operating system, once a dark and mysterious
area whose code was restricted to a small number of programmers, can now be
readily examined, understood, and modified by anybody with the requisite skills.
Linux has helped to democratize operating systems. The Linux kernel remains a
large and complex body of code, however, and would-be kernel hackers need an
entry point where they can approach the code without being overwhelmed by complexity.
Often, device drivers provide that gateway.
Device drivers take on a special role in the Linux kernel. They are distinct “black
boxes” that make a particular piece of hardware respond to a well-defined internal
programming interface; they hide completely the details of how the device works.
User activities are performed by means of a set of standardized calls that are independent
of the specific driver; mapping those calls to device-specific operations that act
on real hardware is then the role of the device driver. This programming interface is
such that drivers can be built separately from the rest of the kernel and “plugged in”
at runtime when needed. This modularity makes Linux drivers easy to write, to the
point that there are now hundreds of them available.
There are a number of reasons to be interested in the writing of Linux device drivers.
The rate at which new hardware becomes available (and obsolete!) alone guarantees
that driver writers will be busy for the foreseeable future. Individuals may need to
know about drivers in order to gain access to a particular device that is of interest to
them. Hardware vendors, by making a Linux driver available for their products, can
add the large and growing Linux user base to their potential markets. And the open
source nature of the Linux system means that if the driver writer wishes, the source
to a driver can be quickly disseminated to millions of users.

Thứ Bảy, 4 tháng 6, 2011 20:19 Đọc tiếp >>

The Role of the Device Driver

As a programmer, you are able to make your own choices about your driver, and
choose an acceptable trade-off between the programming time required and the flexibility
of the result. Though it may appear strange to say that a driver is “flexible,” we
like this word because it emphasizes that the role of a device driver is providing
mechanism, not policy.
The distinction between mechanism and policy is one of the best ideas behind the
Unix design. Most programming problems can indeed be split into two parts: “what
capabilities are to be provided” (the mechanism) and “how those capabilities can be
used” (the policy). If the two issues are addressed by different parts of the program,
or even by different programs altogether, the software package is much easier to
develop and to adapt to particular needs.
For example, Unix management of the graphic display is split between the X server,
which knows the hardware and offers a unified interface to user programs, and the
window and session managers, which implement a particular policy without knowing
anything about the hardware. People can use the same window manager on different
hardware, and different users can run different configurations on the same
workstation. Even completely different desktop environments, such as KDE and
GNOME, can coexist on the same system. Another example is the layered structure
of TCP/IP networking: the operating system offers the socket abstraction, which
implements no policy regarding the data to be transferred, while different servers are
in charge of the services (and their associated policies). Moreover, a server like ftpd
provides the file transfer mechanism, while users can use whatever client they prefer;
both command-line and graphic clients exist, and anyone can write a new user interface
to transfer files.

Thứ Bảy, 4 tháng 6, 2011 20:19 Đọc tiếp >>