Size: 1457
Comment:
|
Size: 1393
Comment: converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
by [wiki:Self:TrevorWoerner Trevor Woerner] | by [[TrevorWoerner|Trevor Woerner]] |
Line 11: | Line 11: |
* [wiki:Self:InitcallMechanism/Introduction Introduction] * [wiki:Self:InitcallMechanism/Motivation Motivation] * [wiki:Self:InitcallMechanism/BackgroundInformation Background Information] * [wiki:Self:InitcallMechanism/SimpleExamples Simple Examples] * [wiki:Self:InitcallMechanism/HowItWorks How It Works] * [wiki:Self:InitcallMechanism/KernelToCode From the Kernel to Stand-Alone Code] * [wiki:Self:InitcallMechanism/References References] |
* [[InitcallMechanism/Introduction|Introduction]] * [[InitcallMechanism/Motivation|Motivation]] * [[InitcallMechanism/BackgroundInformation|Background Information]] * [[InitcallMechanism/SimpleExamples|Simple Examples]] * [[InitcallMechanism/HowItWorks|How It Works]] * [[InitcallMechanism/KernelToCode|From the Kernel to Stand-Alone Code]] * [[InitcallMechanism/References|References]] |
Understanding the Linux Kernel Initcall Mechanism
Creating Dynamic Function-Pointer Call Tables
Abstract
While browsing through the Linux kernel, I came upon a technique for creating a segment of function pointers which can be called at a later time in the order that they are inserted into the segment. The kernel uses this mechanism to call device driver initialization routines at boot-up. I had a hard time finding clear information about what was going on and how it worked. After much googling (and some code doodling) I understand what is happening. This paper is an attempt at putting what I understand of this process down on paper so others may hopefully find it useful.
NOTE: This technique depends on, and requires the use of, the GNU compiler and linker tools. Additionally, the ELF binary executable format must be used. This is not a general-puropse ANSI-C compliant technique.