Team LiB
Previous Section Next Section

Exported Symbols

When modules are loaded, they are dynamically linked into the kernel. As with user-space, dynamically linked binaries can call only into external functions that are explicitly exported for use. In the kernel, this is handled via special directives called EXPORT_ SYMBOL() and EXPORT_SYMBOL_GPL().

Functions that are exported are available for use by modules. Functions that are not exported cannot be invoked from modules. The linking and invoking rules are much more stringent for modules than code in the core kernel image. Core code can call any non-static interface in the kernel because all core source files are linked into a single base image. Exported symbols, of course, must be non-static too.

The set of kernel symbols that are exported are known as the exported kernel interfaces or even (gasp) the kernel API.

Exporting a symbol is easy. After the function is declared, it is usually followed by an EXPORT_SYMBOL(). For example,

 * get_pirate_beard_color - return the color of the current pirate's beard.
 * pirate is a global variable accessible to this function.
 * the color is defined in <linux/beard_colors.h>.
int get_pirate_beard_color(void)
        return pirate->beard->color;

Presuming that get_pirate_beard_color() is also declared in an accessible header file, any module can now access it.

Some developers want their interfaces accessible to only GPL-compliant modules. This is enforced by the kernel linker through use of the MODULE_LICENSE(). If you wanted the previous function accessible to only modules that labeled themselves as GPL licensed, you would use instead


If your code is configurable as a module, you must ensure that when compiled as a module all interfaces that it uses are exported. Otherwise linking errors (and a broken module) will result.

    Team LiB
    Previous Section Next Section