What You Will Learn

Prerequisites

What Are Kernel Module Parameters?

When you write a kernel module, sometimes you want to change its behaviour based on runtime input rather than hardcoding values inside the source code. For example, you might want to control the verbosity of debug messages, or pass a device name, or set a timeout value — all without touching the source and recompiling.

This is exactly what kernel module parameters allow. They are variables declared inside your module that can be set from the command line at load time, or even changed later through the sysfs filesystem while the module is running. In the Linux 6.x kernel, this feature is mature, well-supported, and widely used in real device drivers.

The module_param() Macro — Syntax and Usage

The kernel provides the module_param() macro to register a module parameter. You must include <linux/moduleparam.h> in your module source (this is usually pulled in transitively through <linux/module.h>).

The macro takes three arguments:

Here is a complete, minimal example of declaring two module parameters — an integer and a string:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

/* Declare parameters with defaults */
static int  mp_debug_level = 0;
static char *mp_strparam   = "My string param";

/* Register them with the kernel */
module_param(mp_debug_level, int,   0660);
module_param(mp_strparam,    charp, 0660);

/* Describe each parameter — shown by modinfo */
MODULE_PARM_DESC(mp_debug_level,
    "Debug level [0-2]; 0 => no debug messages, 2 => high verbosity");
MODULE_PARM_DESC(mp_strparam,
    "A demo string parameter");

static int __init mymod_init(void)
{
    pr_info("mymod: inserted\n");
    pr_info("mp_debug_level=%d  mp_strparam=%s\n",
            mp_debug_level, mp_strparam);
    return 0;
}

static void __exit mymod_exit(void)
{
    pr_info("mymod: removed\n");
}

module_init(mymod_init);
module_exit(mymod_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("EmbeddedPathashala");
MODULE_DESCRIPTION("Module parameter demo — Linux 6.x");

A few important things to note about this code:

• The variables must be declared static — they belong to the module’s scope only.
• The default values you assign in the declaration are used when the user does not pass anything.
• charp is the kernel’s type name for a char * (character pointer / string).
• MODULE_PARM_DESC() is optional but strongly recommended — it makes your module self-documenting.
• In Linux 6.x the macro internals have not changed from a usage standpoint, so this same pattern works identically on modern kernels.

Inspecting Parameters Before Loading — modinfo

Before you even load a kernel module, you can check what parameters it accepts using the modinfo command. This reads the compiled .ko file directly and prints metadata including all registered parameters:

$ modinfo -p ./mymod.ko
parm:   mp_debug_level:Debug level [0-2]; 0 => no debug messages, 2 => high verbosity (int)
parm:   mp_strparam:A demo string parameter (charp)

The format is: parameter_name : description (data_type). This is what gets populated from your MODULE_PARM_DESC() calls. It is useful for end users and system integrators who need to understand what the module accepts without reading the source code.

Passing Kernel Module Parameters at Load Time

When you load a module using insmod, parameters are passed as key-value pairs right on the command line. If you do not pass them, the variables retain their default values.

Loading without parameters (uses defaults):

sudo dmesg -C
sudo insmod ./mymod.ko
dmesg

You will see output like:

[ 1234.000001] mymod: inserted
[ 1234.000002] mp_debug_level=0  mp_strparam=My string param

Loading with explicit parameter values:

sudo rmmod mymod
sudo insmod ./mymod.ko mp_debug_level=2 mp_strparam="Hello from EmbeddedPathashala"
dmesg

Output:

[ 1300.000001] mymod: inserted
[ 1300.000002] mp_debug_level=2  mp_strparam=Hello from EmbeddedPathashala

Reading and Writing Parameters at Runtime — sysfs

This is where kernel module parameters become truly powerful. When you set the permission argument in module_param() to a non-zero value like 0660, the kernel automatically creates pseudo-files under /sys/module/<module-name>/parameters/. These files represent your parameters and can be read or written at any time while the module is loaded — without reloading the module.

Here is how you work with these files in practice:

Check the current value of a parameter:

sudo cat /sys/module/mymod/parameters/mp_debug_level
2

Change the value at runtime (no module reload needed):

sudo bash -c "echo 0 > /sys/module/mymod/parameters/mp_debug_level"
sudo cat /sys/module/mymod/parameters/mp_debug_level
0

This is extremely useful in production. For example, you can increase the debug level on a running device to capture diagnostic messages and then reduce it again without any downtime. Device drivers in real products use this technique extensively.

All Supported Module Parameter Data Types

The kernel supports several built-in parameter types. You do not need to write any custom parsing code — the kernel handles conversion from the string representation the user types to the actual C type automatically.

The kernel also supports arrays of these types using module_param_array(), which is covered in an advanced lecture. For most use cases, the standard types above are more than sufficient.

Permission Bits for sysfs Files — Best Practice

The third argument to module_param() sets the file permissions of the corresponding sysfs entry. This is an octal value, just like what you use with chmod. The kernel community and the official kernel coding style checker (scripts/checkpatch.pl) both recommend using octal literals rather than symbolic macros like S_IRUSR.

/* Recommended style per kernel checkpatch — use octal, not symbolic */
module_param(mp_debug_level, int, 0660);

/* Avoid this even though it is technically valid */
/* module_param(mp_debug_level, int, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP); */

Making a Parameter Mandatory — Validation at Init Time

By default all kernel module parameters are optional. The module will load and use the default value if you do not pass a parameter. But what if your driver absolutely needs a specific value to function correctly? For example, a device address or a hardware channel number that has no sensible default?

The kernel does not have a built-in “mandatory parameter” mechanism. The standard approach is to check the parameter value inside your module_init() function and return an error if it is still at the default (usually 0 or NULL) or out of an expected range. This is a straightforward technique used by many real drivers.

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>

static int control_level = 0;
module_param(control_level, int, 0660);
MODULE_PARM_DESC(control_level,
    "Hardware control level [1-5]. MANDATORY — module will not load without this.");

static int __init mydriver_init(void)
{
    /* Validate the mandatory parameter */
    if (control_level  5) {
        pr_err("mydriver: 'control_level' must be in range [1-5]. "
               "Pass it as: insmod mydriver.ko control_level=\n");
        return -EINVAL;
    }

    pr_info("mydriver: loaded successfully with control_level=%d\n",
            control_level);
    return 0;
}

static void __exit mydriver_exit(void)
{
    pr_info("mydriver: unloaded\n");
}

module_init(mydriver_init);
module_exit(mydriver_exit);
MODULE_LICENSE("GPL");

When the user tries to load this module without the parameter:

sudo insmod ./mydriver.ko
# dmesg will show:
# mydriver: 'control_level' must be in range [1-5]. Pass it as: insmod mydriver.ko control_level=<1..5>
# insmod: ERROR: could not insert module ./mydriver.ko: Invalid argument

When the user provides the correct value:

sudo insmod ./mydriver.ko control_level=3
# dmesg will show:
# mydriver: loaded successfully with control_level=3

Best Practices for Kernel Module Parameters

Common Mistakes and Troubleshooting

/* Wrong */
int mp_debug_level = 0;

/* Correct */
static int mp_debug_level = 0;

static char *my_str = "default";
/* Wrong — using int for a char pointer */
module_param(my_str, int, 0660);

/* Correct */
module_param(my_str, charp, 0660);

Real-World Use Cases in Linux Device Drivers

Module parameters are not just a learning exercise — they are used constantly in production Linux drivers. Here are common real-world applications:

Summary and Key Takeaways

Frequently Asked Questions

Further Reading and References