Module_Driver_printk – Basic Structure and Log Printing of Modules

1. Creating C and Makefile Files

Command to create a folder

mkdir <folder_name>

Creating a file

touch <file_name>

Deleting a folder (non-empty)

rm -r <folder_name>

-r option: Recursively delete, which means deleting all files and subdirectories under the directory.

Force delete (avoid confirmation prompt)

rm -rf <file_name>

-f option: Force delete, ignore non-existent files, and do not prompt for confirmation.

2. Basic Format of C Files

#include <linux/init.h>       // Functions related to driver initialization
#include <linux/module.h>     // Basic module functions
#include <linux/kernel.h>     // Basic kernel functions (e.g., printk)

// Driver's exit function
static int __init demo_init(void)
{
    // __init is used to modify the demo_init function to place this function in the init code section
    // __init is defined in init.h  #define __init        __section(.init.text)
    // The section attribute is used to tell the compiler (linux gcc) that the modified variable or function should be placed in a specific section when compiling the executable file
    printk("hello Linux\n");
    return 0;
}

// Driver's entry function (executed by rmmod)
static void __exit demo_exit(void)
{
    printk("Bye Linux\n");
}

module_init(demo_init);         // Modifies the entry function of the modular driver
module_exit(demo_exit);         // Modifies the exit function of the modular driver

MODULE_LICENSE("GPL");          // Must declare GPL license
MODULE_AUTHOR("Your Name");     // Author information
MODULE_DESCRIPTION("Basic Character Device Driver Template");  // Description information
MODULE_VERSION("1.0");          // Version number

2.1 `static` (Static Function Modifier)

• Function: Limits the scope of the function to be visible only within the current .c file, avoiding name conflicts with functions in other files.
• Kernel Driver Requirement: The entry and exit functions in the driver, as well as internal helper functions, are usually modified with static because they do not need to be called by other files and are only used internally in this driver. This is a basic specification for modularizing kernel code.

2.2 `int` (Function Return Value Type)

• Function: Declares that the function returns an integer, which indicates the result of the driver loading.
• Kernel Convention:

• Returning 0 indicates that the driver initialization was successful (insmod will execute successfully).
• Returning a negative number (such as ENOMEM, EIO, etc. kernel error codes) indicates that initialization failed, and the kernel will abandon loading this driver and release any allocated resources.

• This is one of the core differences between the entry function and the exit function (void type), as the kernel needs to determine whether to load the driver based on the return value of the entry function.

2.3 `__init` (Kernel Initialization Attribute Macro)

• Function: Tells the kernel compiler that this function is executed only once when the driver is loaded (insmod), and after execution, it can be released by the kernel to save memory.
• Underlying Implementation: __init is a macro defined by the kernel (in <linux/init.h>), which places the function in the .init.text section (initialization code section) of the kernel image. After the kernel starts or the module is loaded, this section of memory will be released (for modules, it will not be released upon unloading, but will not be used again until the module is unloaded).
• Applicable Scenario: Only used for the entry function of the driver (the function registered with module_init), as the entry function is executed only once during loading and does not need to be retained afterwards.

2.4. `__exit` (Kernel Exit Attribute Macro)

• Function: Tells the kernel compiler that this function is executed only once when the driver is unloaded (rmmod), and is a dedicated function for the module exit phase.
• Underlying Implementation: __exit is a macro defined by the kernel (in <linux/init.h>), which places the function in the .exit.text section (a memory area specifically for exit code).
• Special Features:

• For “module drivers” (.ko files):.exit.text section will be loaded with the module and executed only during rmmod, and after unloading, it will be released along with the module’s memory.
• For “kernel built-in drivers” (drivers compiled into the kernel): these drivers cannot be unloaded, so functions modified with __exit will be ignored by the compiler (to avoid wasting memory).

• Applicable Scenario: Only used for the exit function of the driver (the function registered with module_exit), as the exit function is executed only once during unloading.

2.5 `module_init(demo_init);`

• Function: Registers the function demo_init as the driver’s entry function (initialization function).
• Trigger Timing: When loading the driver module (.ko) via insmod or modprobe, the kernel will automatically call the demo_init function to complete the driver initialization work (such as registering devices, allocating resources, initializing hardware, etc.).
• Essence: module_init is a macro defined by the kernel (in <linux/module.h>), which stores the function pointer of demo_init in the kernel’s module management linked list, ensuring it is called during loading.

2.6 `module_exit(demo_exit);`

• Function: Registers the function demo_exit as the driver’s exit function (cleanup function).
• Trigger Timing: When unloading the driver module via rmmod, the kernel will automatically call the demo_exit function to complete the driver cleanup work (such as unregistering devices, releasing resources, restoring hardware state, etc.).
• Essence: Similar to module_init, the module_exit macro registers the function pointer of demo_exit in the kernel, ensuring it is called during unloading.

2.7 Module Metadata Declaration (`MODULE_xxx` Series Macros)

These macros are used to declare the basic information of the module to the kernel, which will store this information in the module descriptor and can be viewed using the modinfo command (for example, modinfo demo.ko), while some information (such as license) will affect the loading of the module.

1. MODULE_LICENSE("GPL");

• Function: Declares the open-source license that the driver follows (must be specified).
• Key Significance:

• The Linux kernel is under the GPL license, and if the driver uses MODULE_LICENSE("GPL"), it can call internal functions marked as EXPORT_SYMBOL_GPL in the kernel (these functions are only open to GPL-compatible modules).
• If not declared or declared as a non-GPL license (such as Proprietary), the kernel will issue a warning during loading (kernel taint), and it will not be able to use GPL-exclusive kernel interfaces.

• Common Values: "GPL", "GPL v2", "MIT", etc. (must be compatible with the kernel license).

2. MODULE_AUTHOR("Your Name");

• Function: Declares the author of the driver (name or email), facilitating tracing back to the code’s responsible person.

3. MODULE_DESCRIPTION("Basic Character Device Driver Template");

• Function: Briefly describes the function of the driver (e.g., “Driver for controlling GPIO lights”, “I2C sensor data acquisition driver”), making it easier for users to understand the module’s purpose.

4. MODULE_VERSION("1.0");

• Function: Declares the version number of the driver, facilitating version management (e.g., subsequent updates can be marked as 1.1, 2.0, etc.).

3. Basic Format of Makefile

# External Compilation
# Use the makefile in the kernel source to compile

# Variable definitions and module declarations
# First specify the current directory
PWD ?= $(shell pwd)
# Kernel source path
KERNELDIR:=/home/ubuntu/work/linux/tspi_linux_sdk_20230916/Release/kernel
# Variables recognized by the kernel Makefile, used to declare the kernel module to be compiled (.ko file)
obj-m += demo.o

# Execute make default target module
module:
    make -C $(KERNELDIR) M=$(PWD) ARCH=arm64 modules
    
    @# -C $(KERNELDIR) switches to the kernel source directory from the current directory and uses the kernel source makefile to perform make
    @# M=$(PWD) compiles only the driver files in the current directory
    @# ARCH=arm64 specifies the compilation architecture
    
# Execute make clean call    
clean:
    make -C $(KERNELDIR) M=$(PWD) ARCH=arm64 clean

3.1 `$(shell pwd)` in `$`

• $(...) is the syntax for referencing functions in Makefile, and $ is the prefix that triggers this syntax.
• Here, shell is a built-in function in Makefile (used to execute Shell commands), and $(shell pwd)<code> means: "Call the Shell command <code>pwd (get the current directory path), and return the output of the command as the return value of this function”.
• $ is part of the Makefile syntax used to distinguish between “ordinary text” and “variables/functions that need to be parsed”. For example:

• Writing shell pwd directly would be treated as a normal string and would not execute the command;
• Adding $ and parentheses $(shell pwd), make will recognize it as “a function to be executed”.

3.2 `$(KERNELDIR)` in `$`

• $ is the syntax prefix for referencing variables in Makefile, and $(variable_name) means “get the value of that variable”.
• Here, KERNELDIR and PWD are variables defined in your Makefile:

• $(KERNELDIR) will be replaced with the path of the kernel source (for example, /home/ubuntu/work/linux/.../kernel).
• $(PWD) will be replaced with the path of the current driver directory (for example, /home/jimmy/tsp_device/1_1module_driver).

3.3 Why use `modules`?

The kernel Makefile supports various compilation targets (such as vmlinux to compile the kernel image, bzImage to generate a compressed kernel, install to install the kernel, etc.), while modules is specifically used for compiling standalone kernel modules (.ko files).

3.4 Compilation Logic

The kernel Makefile will identify the modules to be compiled based on the obj-m variable (you defined obj-m += demo.o), and then execute the following steps:

1. Compile the source file (such as demo.c) to generate the object file (demo.o).
2. Process module dependencies and linking information to generate auxiliary files (such as demo.mod.c, demo.mod.o).
3. Finally, link these files into a loadable kernel module (demo.ko).

4. Cross-compiling and Loading/Unloading Modules

On the Linux platform, create C and Makefile files, and execute the make command in that directory

jimmy@ubuntu:~/tsp_device/1_1module_driver$ ls
demo.c  Makefile

# Execute make command
jimmy@ubuntu:~/tsp_device/1_1module_driver$ make
make -C /home/jimmy/android/kernel M=/home/jimmy/tsp_device/1_1module_driver ARCH=arm64 modules
make[1]: Entering directory "/home/jimmy/android/kernel"
CC [M]  /home/jimmy/tsp_device/1_1module_driver/demo.o
Building modules, stage 2.
MODPOST 1 modules
CC      /home/jimmy/tsp_device/1_1module_driver/demo.mod.o
LD [M]  /home/jimmy/tsp_device/1_1module_driver/demo.ko
make[1]: Leaving directory "/home/jimmy/android/kernel"

# Make execution completed, generating intermediate files and standalone kernel module files (.ko files)
jimmy@ubuntu:~/tsp_device/1_1module_driver$ ls
demo.c  demo.ko  demo.mod.c  demo.mod.o  demo.o  Makefile  modules.order  Module.symvers

4.1 Compiling Intermediate Files

The generation order and dependency relationship of these files during the compilation process are:

demo.c → (compilation) → demo.o

demo.mod.c (automatically generated) → (compilation) → demo.mod.o

demo.o + demo.mod.o → (linking) → demo.ko

File	Type / Source	Core Function
`<span>demo.c</span>`	Source code (manually written)	Core logic code of the driver module, including initialization, exit, and other function implementations.
`<span>Makefile</span>`	Compilation script (manually written)	Defines compilation rules, guiding the `<span>make</span>` tool to call the kernel source and toolchain to complete module compilation.
`<span>demo.o</span>`	Intermediate object file (compiled)	`<span>demo.c</span>` compiled binary file, containing the module’s machine instructions (not linked).
`<span>demo.mod.c</span>`	Automatically generated dependency file	Automatically generated by the kernel, records module metadata (dependency symbols, licenses, etc.), used for matching kernel interfaces during linking.
`<span>demo.mod.o</span>`	Intermediate object file (compiled)	`<span>demo.mod.c</span>` compiled binary file, carrying module dependency information, participating in the final linking.
`<span>demo.ko</span>`	Final product (linked)	Loadable kernel module, linked from `<span>demo.o</span>` and `<span>demo.mod.o</span>`, loaded and run via `<span>insmod</span>`.
`<span>modules.order</span>`	Auxiliary file (compiled)	Records the module compilation order, facilitating multi-module management.
`<span>Module.symvers</span>`	Auxiliary file (compiled)	Records the kernel symbols exported by the module and their checksums, ensuring compatibility with the kernel / other modules.

In the Windows environment,Win+R enters the terminal

4.2 Using adb push

adb push is a commonly used command of the Android Debug Bridge (ADB) to upload (push) files/directories from the computer to the specified path on Android devices (phones, emulators, development boards, etc.). The following is the detailed usage:

4.2.1 Basic Syntax

adb push <local_file/directory_path> <device_target_path>

• <local_file/directory_path>: The absolute path / relative path of the file or directory to be pushed from the computer.
• <device_target_path>: The path on the Android device to receive the file (must specify the full path, and the device must have write permissions).

4.2.2 Prerequisites

1. Enable Device Debugging Mode: The Android device must enable “Developer Options” and “USB Debugging” (Path: Settings → About Phone → Tap Version Number repeatedly to activate Developer Options, then enter Developer Options to enable USB Debugging).
2. Connect Device: Connect the computer and device with a USB cable, and execute adb devices in the computer terminal to confirm that the device is connected normally (displaying the device serial number indicates a successful connection).

adb push C:\demo.ko /data/local/tmp/

4.3 Using adb shell

When entering the Linux command line environment of the Android device using adb shell in the Windows command line, / and other system directories are read-only by default, and under normal permissions, it may not be possible to transfer files to the system partition, load kernel modules, or view the contents of certain directories (such as /data); at this time, you can execute adb root in the Windows cmd to obtain root permissions, thus resolving these permission restrictions.

adb root

Or use the su command in adb shell to gain permissions

su

Enter the /data directory to view the local directory

rk3566_tspi:/ # cd data
rk3566_tspi:/data # ls
adb            app-private   drm          misc         preloads                   system       user_de
anr            app-staging   gsi          misc_ce      property                   system_ce    vendor
apex           backup        incremental  misc_de      resource-cache             system_de    vendor_ce
app            bootchart     local        nfc          rollback                   tombstones   vendor_de
app-asec       cache         lost+found   ota          rollback-observer          tsp_driver
app-ephemeral  dalvik-cache  media        ota_package  server_configurable_flags  unencrypted
app-lib        data          mediadrm     per_boot     ss                         user

Enter the tsp_driver directory

rk3566_tspi:/data/tsp_driver # ls
printf.ko

4.4 Using insmod to Load Modules

To conveniently view the print effect, you can check the logs using the following methods

4.4.1 Use `dmesg` Command to View Kernel Logs

This is the most common way, dmesg will print the contents of the kernel log buffer (including the output of printk):

# After loading the module, execute dmesg to view the latest logs
dmesg | tail  # View the last few lines (latest logs)

Example: If the module contains printk("tsp_driver loaded\n");, executing dmesg | tail after loading will show something like:

[12345.678901] tsp_driver loaded

4.4.2 Real-time Monitoring of Kernel Logs (Using `dmesg -w`)

If you want to view the output of printk in real-time (requires root permissions), you can execute the following before loading the module:

dmesg -w  # Continuously monitor kernel logs, new content will be displayed immediately after loading the module

Then load the module in another adb shell window, and the current window will output the content of printk in real-time.

Execute insmod in the tsp_driver directory

insmod demo.ko

to see the corresponding printk content in the dmesg -w window

[ 1372.277187] Hello, world!

rk3566_tspi:/data/tsp_driver # insmod printf.ko
rk3566_tspi:/data/tsp_driver # lsmod
Module                  Size  Used by
printf                 16384  0
bcmdhd               1175552  0

4.5 Using rmmod to Unload Modules

rk3566_tspi:/data/tsp_driver # lsmod
Module                  Size  Used by
printf                 16384  0
bcmdhd               1175552  0
rk3566_tspi:/data/tsp_driver # rmmod printf.ko
rk3566_tspi:/data/tsp_driver # lsmod
Module                  Size  Used by
bcmdhd               1175552  0

to see the corresponding printk content in the dmesg -w window

Linux Embedded Driver Development

Module_Driver_printk – Basic Structure and Log Printing of Modules

1. Creating C and Makefile Files

2. Basic Format of C Files

2.1 `<span>static</span>` (Static Function Modifier)

2.2 `<span>int</span>` (Function Return Value Type)

2.3 `<span>__init</span>` (Kernel Initialization Attribute Macro)

2.4. `<span>__exit</span>` (Kernel Exit Attribute Macro)

2.5 `<span>module_init(demo_init);</span>`

2.6 `<span>module_exit(demo_exit);</span>`

2.7 Module Metadata Declaration (`<span>MODULE_xxx</span>` Series Macros)

3. Basic Format of Makefile

3.1 `<span>$(shell pwd)</span>` in `<span>$</span>`

3.2 `<span>$(KERNELDIR)</span>` in `<span>$</span>`

3.3 Why use `<span>modules</span>`?

3.4 Compilation Logic

4. Cross-compiling and Loading/Unloading Modules

4.1 Compiling Intermediate Files

4.2 Using adb push

4.2.1 Basic Syntax

4.2.2 Prerequisites

4.3 Using adb shell

4.4 Using insmod to Load Modules

4.4.1 Use `<span>dmesg</span>` Command to View Kernel Logs

4.4.2 Real-time Monitoring of Kernel Logs (Using `<span>dmesg -w</span>`)

4.5 Using rmmod to Unload Modules

Leave a Comment Cancel reply

Module_Driver_printk – Basic Structure and Log Printing of Modules

1. Creating C and Makefile Files

2. Basic Format of C Files

2.1 <span>static</span> (Static Function Modifier)

2.2 <span>int</span> (Function Return Value Type)

2.3 <span>__init</span> (Kernel Initialization Attribute Macro)

2.4. <span>__exit</span> (Kernel Exit Attribute Macro)

2.5 <span>module_init(demo_init);</span>

2.6 <span>module_exit(demo_exit);</span>

2.7 Module Metadata Declaration (<span>MODULE_xxx</span> Series Macros)

3. Basic Format of Makefile

3.1 <span>$(shell pwd)</span> in <span>$</span>

3.2 <span>$(KERNELDIR)</span> in <span>$</span>

3.3 Why use <span>modules</span>?

3.4 Compilation Logic

4. Cross-compiling and Loading/Unloading Modules

4.1 Compiling Intermediate Files

4.2 Using adb push

4.2.1 Basic Syntax

4.2.2 Prerequisites

4.3 Using adb shell

4.4 Using insmod to Load Modules

4.4.1 Use <span>dmesg</span> Command to View Kernel Logs

4.4.2 Real-time Monitoring of Kernel Logs (Using <span>dmesg -w</span>)

4.5 Using rmmod to Unload Modules

Related posts

Leave a Comment Cancel reply

2.1 `<span>static</span>` (Static Function Modifier)

2.2 `<span>int</span>` (Function Return Value Type)

2.3 `<span>__init</span>` (Kernel Initialization Attribute Macro)

2.4. `<span>__exit</span>` (Kernel Exit Attribute Macro)

2.5 `<span>module_init(demo_init);</span>`

2.6 `<span>module_exit(demo_exit);</span>`

2.7 Module Metadata Declaration (`<span>MODULE_xxx</span>` Series Macros)

3.1 `<span>$(shell pwd)</span>` in `<span>$</span>`

3.2 `<span>$(KERNELDIR)</span>` in `<span>$</span>`

3.3 Why use `<span>modules</span>`?

4.4.1 Use `<span>dmesg</span>` Command to View Kernel Logs

4.4.2 Real-time Monitoring of Kernel Logs (Using `<span>dmesg -w</span>`)