Principles of Dynamic Module Loading in Embedded Linux

Source | Embedded Intelligence Bureau

Sometimes we see colleagues discussing memory-related issues in embedded development. Today, I would like to share the principles of dynamic module loading in embedded development.

1. Design Philosophy and Core Advantages of Dynamic Module Loading

The Linux dynamic module loading mechanism (Loadable Kernel Modules, LKMs) is not merely a technical choice but a systematic solution evolved to meet the core needs of embedded systems—resource efficiency, hardware diversity, security control, and development flexibility—which are deeply integrated into its design philosophy and core advantages, forming a complete adaptive architecture:

1. Resource Constraints and Efficiency First

Embedded devices are limited by memory and storage resources. If all drivers are statically compiled into the kernel, it leads to bloated images and slow boot times. Dynamic modules load resources only when needed,on-demand loading.• Memory Optimization: For example, load the corresponding driver only when using a USB camera, and unload it to free memory when idle.• Storage Reduction: Modules are stored as<span><span>.ko</span></span> files in the file system, avoiding excessive kernel image bloat.

2. Hardware Diversity and Dynamic Adaptation

The hardware fragmentation of embedded devices (such as different sensor combinations in industrial equipment) requires the system to adapt flexibly. Dynamic modules, combined withDevice Tree and auto-detection mechanisms, achieve precise matching of hardware drivers.• Plug and Play: When a USB device is inserted, <span><span>udev</span></span> matches the device ID and loads the driver without needing to reboot the system.• Support for Multiple Hardware Variants: The same kernel image can adapt to different hardware versions by loading different modules.

3. Security and Stability Assurance

In scenarios such as medical devices and industrial control, system crashes or malicious code injection can have serious consequences. Dynamic modules build multi-layer protection throughpermission isolation and signature verification.• Fault Isolation: A single module crash can be recovered by unloading and reloading it, avoiding system-level downtime.• Secure Boot: After enabling <span><span>CONFIG_MODULE_SIG</span></span>, the kernel only loads modules signed by trusted certificates, blocking unauthorized code.

4. Development Efficiency and Maintenance Convenience

Embedded development requires rapid iteration of driver debugging while also addressing hardware changes and issue fixes. Dynamic modules supportindependent compilation and blacklist management, greatly enhancing engineering efficiency.• Rapid Debugging: After modifying the driver, only recompile the module (no need for a complete kernel compilation) and verify instantly using <span><span>insmod</span></span>.• Dynamic Maintenance: Disable conflicting drivers through <span><span>/etc/modprobe.d/blacklist.conf</span></span> without modifying kernel code.

5. Boot Speed and Real-time Optimization

Embedded devices often require fast boot times, while the initialization of complex drivers (such as file systems and network protocol stacks) can slow down the boot process. Dynamic modules supportdeferred loading, delaying the initialization of non-critical drivers.• Boot Acceleration: For example, load the Wi-Fi driver after the system has booted to prioritize core services readiness.• Resource Allocation on Demand: Load memory-intensive modules (such as GPU drivers) only when needed.

2. Detailed Explanation of Module Loading Process Using a “Hello World” Driver as an Example

The following dissects the core steps of Linux module loading through the complete lifecycle of a simple Hello World driver module:

1. Module Code and Compilation

// hello.c
#include <linux/init.h>
#include <linux/module.h>

static int __init hello_init(void) {
    printk("Hello World!\n");  // Kernel space log output
    return 0;
}

static void __exit hello_exit(void) {
    printk("Goodbye World!\n");
}

module_init(hello_init);   // Bind initialization function
module_exit(hello_exit);   // Bind cleanup function
MODULE_LICENSE("GPL");     // Open source license declaration

• Compile to Generate Module:

make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
# Generates hello.ko file

2. User Space Triggered Loading

# Load module
sudo insmod hello.ko

# Check loading result
dmesg | tail -n 1
# Output: Hello World!

• Trigger Method: Users trigger loading through <span>insmod</span> or <span>modprobe</span>, and the kernel receives the <span>init_module</span> system call.

3. Kernel Space Processing Flow

1. Permission and Security Checks• Capability Check: Verify if the process has <span>CAP_SYS_MODULE</span> permission (usually requires root privileges).• Signature Verification: If secure boot is enabled, check if the module’s signature matches the kernel’s trusted certificate.

2. ELF Parsing and Relocation• The kernel parses the ELF format of <span>hello.ko</span>, extracting the code segment (<span>.text</span>), data segment (<span>.data</span>), and symbol table.• Address Relocation: Map the logical addresses in the module to the kernel address space, such as the actual address of the <span>printk</span> function.

3. Symbol Resolution and Compatibility Check• Symbol Binding: Link the <span>printk</span> in the module to the kernel-exported symbol address (via <span>EXPORT_SYMBOL</span>).• Version Check: Check the module’s Vermagic information (kernel version, compiler version); if inconsistent, refuse to load.

4. Initialization and Resource Registration• Call the <span>hello_init()</span> function, outputting the log “Hello World!”.• Register the module to the kernel module list (<span>struct module</span>), and generate status files in the <span>/sys/module/hello</span> directory.

4. Module Unloading and Resource Release

# Unload module
sudo rmmod hello

# Verify unload result
dmesg | tail -n 1
# Output: Goodbye World!

• Reference Count Check: The kernel checks the module’s <span>refcnt</span> field, allowing unload only if no other modules depend on it.• Cleanup Execution: Call <span>hello_exit()</span> to release resources and remove the <span>/sys/module/hello</span> directory.

5. Dependency Management (Extended Scenario)

If <span>hello.ko</span> depends on other modules (such as <span>dep_module.ko</span>):

1. Generate Dependency Relationships:

   sudo depmod -a  # Generate /modules.dep file
   

2. Automatically Load Dependencies:

   sudo modprobe hello  # Automatically load dep_module.ko
   

The design philosophy and core advantages of the Linux dynamic module loading mechanismare deeply integrated, addressing the challenges of resource constraints and hardware fragmentation while achieving a unified approach to security, efficiency, and flexibility through a modular architecture.

———— END ————

●Are the touch functions integrated into MCUs this advanced?

●Sharing an embedded cross-platform open-source library

●Embedded AI Development | Deploying DeepSeek on the ELF 2 Development Board

Follow our public account and reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.

Click “Read Original” for more shares.