Character devices
A character (char) device is one that can be accessed as a stream of
bytes (like a file); a char driver is in charge of implementing this
behavior.
The only relevant difference between a char device and a regular file
is that youcan always move back and forth in the regular file, whereas
most char devicesare just data channels, which you can only access
sequentially.
Block devices
Like char devices, block devices are accessed by filesystem nodes
in the /dev directory. A block device is a device (e.g., a disk) that
can host a filesystem.
Like achar device, each block device is accessed through a filesystem node, and the difference between them is transparent to the user. Block drivers have a completelydifferent interface to the kernel than char drivers.
Network interfaces
Any network transaction is made through an interface, that is, a device that isable to exchange data with other hosts. Usually, an interface is a hardware device, but it might also be a pure software device, like the loopback interface.
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
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.”
An application can call functions it
doesn’t define: the linking stage resolves external references using
the appropriate library of func-tions. 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.
A module runs in kernel space, whereas applications run in user space.
Applications are laid out in virtual memory with a very large stack area. The stack, of course, is used to hold the function call history and all automatic variables created by currently active functions. The kernel, instead, has a very small stack; it can be as small as a single, 4096-byte page. Your functions must share that stack with the entire kernel-space call chain. Thus, it is never a good idea to declare large auto-matic variables; if you need larger structures, you should allocate them dynamically
at call time.
Quick Reference
This section summarizes the kernel functions, variables, macros, and /proc files that
we’ve touched on in this chapter. It is meant to act as a reference. Each item is listed
after the relevant header file, if any. A similar section appears at the end of almost
every chapter from here on, summarizing the new symbols introduced in the chap-
ter. Entries in this section generally appear in the same order in which they were
introduced in the chapter:
insmod
modprobe
rmmod
User-space utilities that load modules into the running kernels and remove
them.
#include <linux/init.h>
module_init(init_function);
module_exit(cleanup_function);
Macros that designate a module’s initialization and cleanup functions.
__init
__initdata
__exit
__exitdata
Markers for functions (__init and __exit) and data (__initdata and __exitdata)
that are only used at module initialization or cleanup time. Items marked for ini-
tialization may be discarded once initialization completes; the exit items may be
discarded if module unloading has not been configured into the kernel. These
markers work by causing the relevant objects to be placed in a special ELF sec-
tion in the executable file.
#include <linux/sched.h>
One of the most important header files. This file contains definitions of much of
the kernel API used by the driver, including functions for sleeping and numer-
ous variable declarations.
struct task_struct *current;
The current process.
current->pid
current->comm
The process ID and command name for the current process.
obj-m
A makefile symbol used by the kernel build system to determine which modules
should be built in the current directory.
/sys/module
/proc/modules
/sys/module is a sysfs directory hierarchy containing information on currently-
loaded modules. /proc/modules is the older, single-file version of that informa-
tion. Entries contain the module name, the amount of memory each module
occupies, and the usage count. Extra strings are appended to each line to specify
flags that are currently active for the module.
vermagic.o
An object file from the kernel source directory that describes the environment a
module was built for.
#include <linux/module.h>
Required header. It must be included by a module source.
#include <linux/version.h>
A header file containing information on the version of the kernel being built.
LINUX_VERSION_CODE
Integer macro, useful to #ifdef version dependencies.
EXPORT_SYMBOL (symbol);
EXPORT_SYMBOL_GPL (symbol);
Macro used to export a symbol to the kernel. The second form exports without
using versioning information, and the third limits the export to GPL-licensed
modules.
MODULE_AUTHOR(author);
MODULE_DESCRIPTION(description);
MODULE_VERSION(version_string);
MODULE_DEVICE_TABLE(table_info);
MODULE_ALIAS(alternate_name);
Place documentation on the module in the object file.
module_init(init_function);
module_exit(exit_function);
Macros that declare a module’s initialization and cleanup functions.
#include <linux/moduleparam.h>
module_param(variable, type, perm);
Macro that creates a module parameter that can be adjusted by the user when
the module is loaded (or at boot time for built-in code). The type can be one of
bool, charp, int, invbool, long, short, ushort, uint, ulong, or intarray.
#include <linux/kernel.h>
int printk(const char * fmt, ...);
The analogue of printf for kernel code.