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

2.6. Preliminaries

We are getting closer to looking




at some
actual module code. But first, we need to look at some other things
that need to appear in your module source files. The kernel is a
unique environment, and it imposes its own requirements on code that
would interface with it.

Most kernel code ends up including a fairly large number of header
files to get definitions of functions, data types, and variables.
We'll examine these files as we come to them, but
there are a few that are specific to modules, and must appear in
every loadable module. Thus, just about all module code has the
following:

#include <linux/module.h>
#include <linux/init.h>

module.h contains a great many definitions of
symbols and functions needed by loadable modules. You need
init.h to specify your initialization and
cleanup functions, as we saw in the "hello
world" example above, and which we revisit in the
next section. Most modules also include
moduleparam.h to enable the passing of
parameters to the module at load time; we will get to that shortly.

It is not strictly necessary, but your module really should specify
which license applies to its code. Doing so is just a matter of
including a MODULE_LICENSE line:

MODULE_LICENSE("GPL");

The specific licenses recognized by the kernel are
"GPL" (for any version of the GNU
General Public License), "GPL v2"
(for GPL version two only), "GPL and additional
rights," "Dual
BSD/GPL," "Dual
MPL/GPL," and
"Proprietary." Unless your module
is explicitly marked as being under a free license recognized by the
kernel, it is assumed to be proprietary, and the kernel is
"tainted" when the module is
loaded. As we mentioned in Section 1.6, kernel developers tend to be
unenthusiastic about helping users who experience problems after
loading proprietary modules.

Other descriptive definitions that can be contained within a module
include MODULE_AUTHOR (stating who wrote the
module), MODULE_DESCRIPTION (a human-readable
statement of what the module does), MODULE_VERSION
(for a code revision number; see the comments in
<linux/module.h> for the conventions to
use in creating version strings), MODULE_ALIAS
(another name by which this module can be known), and
MODULE_DEVICE_TABLE (to tell user space about
which devices the module supports).

The various MODULE_ declarations can appear
anywhere within your source file outside of a function. A relatively
recent convention in kernel code, however, is to put these
declarations at the end of the file.