› Linux Kernel Module Parameters

Why Module Parameters Matter in Linux Kernel Development

Think about debugging. You add pr_debug() calls inside your driver to trace what is happening. In production you do not want those messages flooding the kernel log. So you guard them with a debug_level variable. If debug_level is 0, nothing prints. If it is 1, basic messages appear. If it is 2, you get full verbose output.

Without module parameters, you would have to hardcode that value and rebuild the module every time a customer reports a problem. With module parameters, the customer’s engineer can simply do:

sudo insmod mydriver.ko debug_level=2

And immediately get verbose logs without touching a single line of source code. This is the core idea behind the debug_level pattern you will see in almost every real driver in the Linux kernel tree.

How the module_param() Macro Works in Linux 6.x

The kernel uses a bit of linker-level trickery to implement module parameters. When you call module_param(), the preprocessor generates a special structure that the module loader reads when it inserts your module. There is no main() involved at all — the kernel module loader parses the name=value pairs you give at insmod time and matches them to the registered variables.

The macro signature is:

module_param(name, type, perm);

Let us look at each argument one by one.

The Three Arguments of module_param()

Supported Data Types for Kernel Module Parameters

The type argument is not a raw C type. The kernel defines its own type tokens that map to C types internally. Here are all the types you can use in Linux 6.x:

Writing a Kernel Module with Parameters – Complete Example

Here is a clean, minimal kernel module for Linux 6.x that demonstrates two module parameters: an integer debug level and a string name. Everything is written from scratch — no copy from any book or external source — so you can drop this directly into your own project.

// File: myparams.c
// Demonstrates module_param() on Linux 6.x
// Part of EmbeddedPathashala Free Linux Kernel Programming Course

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

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

/* ----- Module Parameters ----- */

/* Integer parameter: debug verbosity level (0 = silent, 2 = verbose) */
static int debug_level;
module_param(debug_level, int, 0660);
MODULE_PARM_DESC(debug_level,
    "Debug verbosity: 0=off, 1=basic, 2=verbose (default: 0)");

/* String parameter: a device name or label */
static char *device_name = "mydevice0";
module_param(device_name, charp, 0444);
MODULE_PARM_DESC(device_name,
    "Name label for this device instance (default: mydevice0)");

/* Boolean parameter: enable an optional feature */
static bool enable_feature;
module_param(enable_feature, bool, 0660);
MODULE_PARM_DESC(enable_feature,
    "Set to 1 to enable the optional feature (default: 0)");

/* ----- Init ----- */
static int __init myparams_init(void)
{
    pr_info("myparams: loaded. device_name=%s debug_level=%d enable_feature=%d\n",
            device_name, debug_level, enable_feature);

    if (debug_level >= 1)
        pr_info("myparams: basic debug info active\n");

    if (debug_level >= 2)
        pr_info("myparams: verbose debug info active\n");

    if (enable_feature)
        pr_info("myparams: optional feature is ON\n");

    return 0;
}

/* ----- Exit ----- */
static void __exit myparams_exit(void)
{
    pr_info("myparams: unloaded\n");
}

module_init(myparams_init);
module_exit(myparams_exit);

And the matching Makefile for Linux 6.x out-of-tree builds:

# Makefile for myparams kernel module
obj-m := myparams.o

KDIR ?= /lib/modules/$(shell uname -r)/build

all:
	make -C $(KDIR) M=$(PWD) modules

clean:
	make -C $(KDIR) M=$(PWD) clean

Building and Loading the Module

# Build
make

# Load with default values (debug_level=0)
sudo insmod myparams.ko

# Load with custom parameters
sudo insmod myparams.ko debug_level=2 device_name=eth_custom enable_feature=1

# Check the kernel log
dmesg | tail -10

# Unload
sudo rmmod myparams

Using modinfo to Inspect Module Parameters Before Loading

One of the best things about documenting your parameters with MODULE_PARM_DESC() is that anyone can read them without loading the module. The modinfo command shows all metadata embedded in the .ko file, including parameters:

# Show only parameter info
modinfo -p myparams.ko

# Example output:
debug_level:Debug verbosity: 0=off, 1=basic, 2=verbose (default: 0) (int)
device_name:Name label for this device instance (default: mydevice0) (charp)
enable_feature:Set to 1 to enable the optional feature (default: 0) (bool)

This is how a support engineer or a customer can find out what knobs your driver exposes before deploying it. Writing a good MODULE_PARM_DESC() for every parameter is a professional habit that saves a lot of debugging time later.

Module Parameters and sysfs – Runtime Modification Without Reloading

When you set a non-zero permission in module_param(name, type, perm), the kernel automatically creates a file for that parameter under /sys/module/<modulename>/parameters/. This is the sysfs interface.

After your module is loaded, you can read and (if the permission allows writes) modify parameters on the fly:

# Read current value of debug_level
cat /sys/module/myparams/parameters/debug_level

# Output: 0

# Change debug_level to 2 at runtime (no reload needed)
echo 2 | sudo tee /sys/module/myparams/parameters/debug_level

# Verify
cat /sys/module/myparams/parameters/debug_level
# Output: 2

This is extremely useful in production systems where you cannot afford to unload and reload a driver but need to increase verbosity temporarily to catch a bug.

Choosing the Right Permission Value

The permission value controls who can read or write the sysfs file. Here are the most common choices:

Permission	sysfs file access	When to use
0	No sysfs file created	Internal-only params that should not be exposed
0444	Read-only for all	Params set at load time, never changed at runtime
0644	Root writes, all read	Runtime-tunable params, readable by users
0660	Root reads+writes, group reads+writes	Sensitive params limited to root and group
0600	Root only, read+write	Security-sensitive params

Best Practices for Kernel Module Parameters in Linux 6.x

Real kernel drivers in the mainline tree follow a consistent set of practices when using module parameters. Here are the key ones to follow in your free Linux kernel programming and device drivers work:

Common Mistakes When Using module_param() – Troubleshooting Guide

Frequently Asked Questions – Linux Kernel Module Parameters