The kernel provides two macros for exporting symbols — export_symbol and export_symbol_gpl. As their names suggest, a distinction is made between exporting general symbols and exporting symbols that may be used only by GPL-compatible code. Again, their purpose is to place the symbols in the appropriate section of the module binary image:
/* For every exported symbol, place a struct in the _ksymtab section */
#define _EXPORT_SYMBOL(sym, sec) \
extern typeof(sym) sym; \
= MODULE_SYMBOL_PREFIX #sym; \
static const struct kernel_symbol _ksymtab_##sym \
_attribute_((section("_ksymtab" sec), unused)) \
#define EXPORT_SYMBOL(sym) \ _EXPORT_SYMBOL(sym, "")
#define EXPORT_SYMBOL_GPL(sym) \ _EXPORT_SYMBOL(sym, "_gpl")
#define EXPORT_SYMBOL_GPL_FUTURE(sym) \ _EXPORT_SYMBOL(sym, "_gpl_future")
At first glance, the definition is anything but clear. Its effect is therefore illustrated by reference to the following example:
The above code is processed by the pre-processor and then looks something like this:
static const char _kstrtab_get_rms
_attribute_((section("_ksymtab_strings"))) = "get_rms";
static const struct kernel_symbol _ksymtab_get_rms
_attribute_used__attribute_((section("_ksymtab ), unused)) =
(unsigned long)&get_rms, _kstrtab_get_rms static const char _kstrtab_no_free_beer
_attribute_((section("_ksymtab_strings"))) = "no_free_beer";
static const struct kernel_symbol __ksymtab_no_free_beer
_attribute_used__attribute_((section("_ksymtab" "_gpl"), unused)) =
(unsigned long)&no_free_beer, _kstrtab_no_free_beer
Two code sections are generated for each exported symbol. They serve the following purpose:
□ _kstrtab_function is stored in the_ksymtab_strings section as a statically defined variable.
Its value is a string that corresponds to the name of the (function) function.
□ A kernel_symbol instance is stored in the_ksymtab (or_kstrtab_gpl) section. It consists of a pointer to the exported function and a pointer to the entry just created in the string table.
This allows the kernel to find the matching code address by reference to the function name in the string; this is needed when resolving references, as is discussed in Section 7.3.4.
module_symbol_prefix can be used to assign a prefix to all exported symbols of a module; this is necessary on some architectures (but most define an empty string as the prefix).
_crc_symbol is used when kernel version control is enabled for exported functions (refer to Section 7.5
for further details); otherwise, it is defined as an empty string as I have assumed here for simplicity's sake.
Continue reading here: Genera Module Information
Was this article helpful?