2.1. Hello, World: The Simplest Module
When the first caveman programmer chiseled the first program on the walls of the first cave computer, it was a program
to paint the string `Hello, world’ in Antelope pictures. Roman programming textbooks began with the `Salut, Mundi’ program.
I don’t know what happens to people who break with this tradition, but I think it’s safer not to find out. We’ll start with a
series of hello world programs that demonstrate the different aspects of the basics of writing a kernel module.
Here’s the simplest module possible. Don’t compile it yet; we’ll cover module compilation in the next section.
/* hello-1.c – The simplest kernel module.
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_ALERT */
{
printk(“<1>Hello world 1.\n”);
// A non 0 return means init_module failed; module can’t be loaded.
return 0;
}
{
printk(KERN_ALERT “Goodbye world 1.\n”);
} Kernel modules must have at least two functions: a “start” (initialization) function called
init_module() which is called when the module is insmoded into the kernel, and an “end” (cleanup)
function called cleanup_module() which is called just before it is rmmoded. Actually, things have
changed starting with kernel 2.3.13. You can now use whatever name you like for the start and end functions of a module. In fact, the new method is the preferred method. However, many
people still use init_module() and cleanup_module() for their start and end
functions.
Typically, init_module() either registers a handler for something with the kernel, or it replaces
one of the kernel functions with its own code (usually code to do something and then call the original function). The
cleanup_module() function is supposed to undo whatever init_module() did, so the
module can be unloaded safely.
Lastly, every kernel module needs to include linux/module.h. We needed to
include linux/kernel.h only for the macro expansion for the
printk() log level, KERN_ALERT, which you’ll learn about in Section 2.1.1.
Despite what you might think, printk() was not meant to communicate information to the user,
even though we used it for exactly this purpose in hello-1! It happens to be a logging
mechanism for the kernel, and is used to log information or give warnings. Therefore, each printk()
statement comes with a priority, which is the <1> and KERN_ALERT you see.
There are 8 priorities and the kernel has macros for them, so you don’t have to use cryptic numbers, and you can view them
(and their meanings) in linux/kernel.h. If you don’t specify a priority level, the
default priority, DEFAULT_MESSAGE_LOGLEVEL, will be used.
practise, don’t use number, like <4>. Always use the macro, like
KERN_WARNING.
If the priority is less than int console_loglevel, the message is printed on your current
terminal. If both syslogd and klogd are running, then the message will also
get appended to /var/log/messages, whether it got printed to the console or not. We use a high
priority, like KERN_ALERT, to make sure the printk() messages get printed to your
console rather than just logged to your logfile. When you write real modules, you’ll want to use priorities that are
meaningful for the situation at hand.
compiled with certain symbols defined. This is because the kernel header files need to behave differently, depending on
whether we’re compiling a kernel module or an executable. You can define symbols using gcc’s -D option, or
with the #define preprocessor command. We’ll cover what you need to do in order to compile kernel modules
in this section.
- -c:
A kernel module is not an independant executable, but an object file which will be linked into the kernel during runtime
using insmod. As a result, modules should be compiled with the -c flag.
- -O2:
The kernel makes extensive use of inline functions, so modules must be compiled with the optimization flag turned
on. Without optimization, some of the assembler macros calls will be mistaken by the compiler for function calls. This
will cause loading the module to fail, since insmod won’t find those functions in the kernel.
- -W -Wall:
A programming mistake can take take your system down. You should always turn on compiler warnings, and this applies to
all your compiling endeavors, not just module compilation.
- -isystem /lib/modules/`uname -r`/build/include:
You must use the kernel headers of the kernel you’re compiling against. Using the default /usr/include/linux won’t work.
- -D__KERNEL__: Defining this symbol tells the header files that the code will be run in
kernel mode, not as a user process.
- -DMODULE: This symbol tells the header files to give the appropriate definitions for a
kernel module.
We use gcc’s -isystem option instead of -I because it tells gcc to surpress some
“unused variable” warnings that -W -Wall causes when you include module.h.
By using -isystem under gcc-3.0, the kernel header files are treated specially, and the warnings are
surpressed. If you instead use -I (or even -isystem under gcc 2.9x), the “unused variable”
warnings will be printed. Just ignore them if they do.
So, let’s look at a simple Makefile for compiling a module named hello-1.c:
Example 2-2. Makefile for a basic kernel module
WARN := -W -Wall -Wstrict-prototypes -Wmissing-prototypes
INCLUDE := -isystem /lib/modules/`uname -r`/build/include
CFLAGS := -O2 -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE}
CC := gcc-3.0
rm -rf {TARGET}.oAs an exercise to the reader, compile hello-1.c and insert it into the kernel with insmod
./hello-1.o (ignore anything you see about tainted kernels; we’ll cover that shortly). Neat, eh? All modules
loaded into the kernel are listed in /proc/modules. Go ahead and cat that file to see that your module
is really a part of the kernel. Congratulations, you are now the author of Linux kernel code! When the novelty wares off,
remove your module from the kernel by using rmmod hello-1. Take a look at
/var/log/messages just to see that it got logged to your system logfile.
Blogged with Flock
Posted by janakiram 