Content-type: text/html; charset=UTF-8
int init_module(void *module_image, unsigned long len, const char *param_values); int finit_module(int fd, const char *param_values, int flags);
Note: glibc provides no header file declaration of init_module() and no wrapper function for finit_module(); see NOTES.
The module_image argument points to a buffer containing the binary image to be loaded; len specifies the size of that buffer. The module image should be a valid ELF image, built for the running kernel.
The param_values argument is a string containing space-delimited specifications of the values for module parameters (defined inside the module using module_param() and module_param_array()). The kernel parses this string and initializes the specified parameters. Each of the parameter specifications has the form:
name[=value[,value...]]
The parameter name is one of those defined within the module using module_param() (see the Linux kernel source file include/linux/moduleparam.h). The parameter value is optional in the case of bool and invbool parameters. Values for array parameters are specified as a comma-separated list.
The flags argument modifies the operation of finit_module(). It is a bit mask value created by ORing together zero or more of the following flags:
There are some safety checks built into a module to ensure that it matches the kernel against which it is loaded. These checks are recorded when the module is built and verified when the module is loaded. First, the module records a "vermagic" string containing the kernel version number and prominent features (such as the CPU type). Second, if the module was built with the CONFIG_MODVERSIONS configuration option enabled, a version hash is recorded for each symbol the module uses. This hash is based on the types of the arguments and return value for the function named by the symbol. In this case, the kernel version number within the "vermagic" string is ignored, as the symbol version hashes are assumed to be sufficiently reliable.
Using the MODULE_INIT_IGNORE_VERMAGIC flag indicates that the "vermagic" string is to be ignored, and the MODULE_INIT_IGNORE_MODVERSIONS flag indicates that the symbol version hashes are to be ignored. If the kernel is built to permit forced loading (i.e., configured with CONFIG_MODULE_FORCE_LOAD), then loading will continue, otherwise it will fail with ENOEXEC as expected for malformed modules.
The following errors may additionally occur for init_module():
The following errors may additionally occur for finit_module():
In addition to the above errors, if the module's init function is executed and returns an error, then init_module() or finit_module() fails and errno is set to the value returned by the init function.
Glibc does not provide a wrapper for finit_module(); call it using syscall(2).
Information about currently loaded modules can be found in /proc/modules and in the file trees under the per-module subdirectories under /sys/module.
See the Linux kernel source file include/linux/module.h for some useful background information.
In Linux 2.4 and earlier, the init_module() system call was rather different:
#include <linux/module.h>
int init_module(const char *name, struct module *image);
(User-space applications can detect which version of init_module() is available by calling query_module(); the latter call fails with the error ENOSYS on Linux 2.6 and later.)
The older version of the system call loads the relocated module image pointed to by image into kernel space and runs the module's init function. The caller is responsible for providing the relocated image (since Linux 2.6, the init_module() system call does the relocation).
The module image begins with a module structure and is followed by code and data as appropriate. Since Linux 2.2, the module structure is defined as follows:
struct module { unsigned long size_of_struct; struct module *next; const char *name; unsigned long size; long usecount; unsigned long flags; unsigned int nsyms; unsigned int ndeps; struct module_symbol *syms; struct module_ref *deps; struct module_ref *refs; int (*init)(void); void (*cleanup)(void); const struct exception_table_entry *ex_table_start; const struct exception_table_entry *ex_table_end; #ifdef __alpha__ unsigned long gp; #endif };
All of the pointer fields, with the exception of next and refs, are expected to point within the module body and be initialized as appropriate for kernel space, that is, relocated with the rest of the module.