Chapter7:Modules
#endif/* Per-cpu data. */
void *percpu;/* The command line arguments (may be mangled). People like
keeping pointers to this stuff */
char *args;
};As this source code extract shows, the structure definition depends on the kernel configuration settings:
❑ KALLSYMSis a configuration option (but only for embedded systems — it is always enabled on
regular machines) that holds in memory a list ofallsymbols defined in the kernel itself and in the
loaded modules (otherwise only the exported functions are stored). This is useful if oops mes-
sages (which are used if the kernel detects a deviation from the normal behavior, for example, if
aNULLpointer is de-referenced) are to output not only hexadecimal numbers but also the names
of the functions involved.
❑ In contrast to kernel versions prior to 2.5, the ability to unload modules must now be config-
ured explicitly. The required additional information is not included in the module data structure
unless the configuration optionMODULE_UNLOADis selected.Other configuration options that occur in conjunction with modules but do not change the definition of
struct moduleare as follows:
❑ MODVERSIONSenables version control; this prevents an obsolete module whose interface defini-
tions no longer match those of the current version from loading into the kernel. Section 7.5 deals
with this in more detail.
❑ MODULE_FORCE_UNLOADenables modules to be removed from the kernel by force, even if there
are still references to the module or the code is being used by other modules. This brute force
method is never needed in normal operation but can be useful during development.
❑ KMODenables the kernel to automatically load modules once they are needed. This requires some
interaction with the userspace, which is described below in the chapter.The elements ofstruct modulehave the following meaning:
❑ stateindicates the current state of the module and can assume one of the values of
module_state:<module.h>
enum module_state
{
MODULE_STATE_LIVE,
MODULE_STATE_COMING,
MODULE_STATE_GOING,
};During loading, the state isMODULE_STATE_COMING. In normal operation (after completion of
all initialization tasks), it isMODULE_STATE_LIVE; and while a module is being removed, it is
MODULE_STATE_GOING.