Linux Device Drivers (3rd Edition) [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Device Drivers (3rd Edition) [Electronic resources] - نسخه متنی

Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








2.2. 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.

The
printk

function is defined in the Linux kernel and made available to
modules; it behaves similarly to the standard C library function
printf. The kernel needs its own printing
function because it runs by itself, without the help of the C
library. The module can call printk because,
after insmod has loaded it, the module is linked
to the kernel and can access the kernel's public
symbols (functions and variables, as detailed in the next section).
The string KERN_ALERT is the priority of the
message.[1] We've specified a high
priority in this module, because a message with the default priority
might not show up anywhere useful, depending on the kernel version
you are running, the version of the
klogd

daemon, and your configuration. You can ignore this issue for now; we
explain it in Chapter 4.

[1] The priority is just a string, such as
<1>, which is prepended to the
printk format string. Note the lack of a comma
after KERN_ALERT; adding a comma there is a common
and annoying typo (which, fortunately, is caught by the
compiler).


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 Section 2.4.

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). The mechanism used to deliver

kernel
messages is described in Chapter 4.

As you can see, writing a module is not as difficult as you might
expectat least, as long as the module is not required to do
anything worthwhile. The hard part is understanding your device and
how to maximize performance. We go deeper into modularization
throughout this chapter and leave device-specific
issues for later chapters.


    / 202