CHAPTER 2 Building and Running

Regardless of the origin of your kernel, building modules for 2.6.x requires that you
have a configured and built kernel tree on your system. This requirement is a change
from previous versions of the kernel, where a current set of header files was suffi-
cient.
The Hello World Module
module:
   #include
   #include
   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.
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#
i had write a article about the makefile used above,allocatted at:
http://blog.chinaunix.net/u2/78601/showart_1711936.html

Because no library is linked to modules, source files should never include the usual
header files, and very special situations being the only exceptions.

A module runs in kernel space, whereas applications run in user space. This concept
is at the base of operating systems theory.

Unix transfers execution from user space to kernel space whenever an application
issues a system call or is suspended by a hardware interrupt.

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.

Often, as you look at the kernel API, you will encounter function names starting with
a double underscore (__). Functions so marked are generally a low-level component
of the interface and should be used with caution. Essentially, the double underscore
says to the programmer: “If you call this function, be sure you know what you are
doing.”

The __init token in the
definition may look a little strange; it is a hint to the kernel that the given function is
used only at initialization time.
The __exit modi-
fier marks the code as being for module unload only (by causing the compiler to
place it in a special ELF section).

One thing you must always bear in mind when registering facilities with the kernel
is that the registration could fail. Even the simplest action often requires memory
allocation, and the required memory may not be available.