› Module Parameters – Advanced Patterns

Passing Multiple Values with module_param_array()

A single module_param() handles one value. But what if your driver supports multiple hardware instances and each one needs its own IRQ number or I/O port? This is where module_param_array() comes in. It lets the user pass a comma-separated list of values at load time.

The macro signature is:

module_param_array(name, type, nump, perm);

The difference from module_param() is the extra nump argument — a pointer to a variable where the kernel stores how many values the user actually passed. If the user passes fewer values than the array size, only those positions are filled.

// File: multiport.c
// Example: multiple I/O ports for a multi-instance driver
// Free Linux Device Drivers Course – EmbeddedPathashala

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

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

#define MAX_PORTS  4

static unsigned int io_ports[MAX_PORTS];
static int num_ports;   /* kernel fills this in */

module_param_array(io_ports, uint, &num_ports, 0444);
MODULE_PARM_DESC(io_ports,
    "I/O base addresses for up to 4 device instances (comma-separated)");

static int __init multiport_init(void)
{
    int i;

    if (num_ports == 0) {
        pr_err("multiport: no I/O ports specified\n");
        return -EINVAL;
    }

    pr_info("multiport: %d port(s) registered\n", num_ports);
    for (i = 0; i < num_ports; i++)
        pr_info("multiport: port[%d] = 0x%x\n", i, io_ports[i]);

    return 0;
}

static void __exit multiport_exit(void)
{
    pr_info("multiport: unloaded\n");
}

module_init(multiport_init);
module_exit(multiport_exit);

Loading this module with three ports looks like this:

sudo insmod multiport.ko io_ports=0x3F8,0x2F8,0x3E8

The kernel parses the comma-separated hex values, fills the array, and sets num_ports = 3. Your init function then loops over exactly the ports the user specified.

The Debug Level Pattern – Used in Production Linux Drivers

This is one of the most widely used patterns in Linux kernel drivers. The idea is simple: you have a single integer parameter called something like debug or debug_level. Every debug message in the driver is guarded by a check against this integer. Higher values give more verbose output.

Here is a clean implementation of this pattern in a driver skeleton:

// debug_level pattern – production-quality implementation
// Free Linux Kernel Programming Course – EmbeddedPathashala

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

MODULE_LICENSE("GPL");

static int debug_level;
module_param(debug_level, int, 0660);
MODULE_PARM_DESC(debug_level,
    "Debug verbosity 0-3: 0=off, 1=info, 2=data path, 3=trace (default: 0)");

/* A convenience macro to avoid repeating the check everywhere */
#define MYDRV_DBG(level, fmt, ...)                          \
    do {                                                    \
        if (debug_level >= (level))                         \
            pr_info("mydrv: " fmt, ##__VA_ARGS__);         \
    } while (0)

static int __init mydrv_init(void)
{
    if (debug_level < 0 || debug_level > 3) {
        pr_err("mydrv: debug_level must be 0-3, got %d\n", debug_level);
        return -EINVAL;
    }

    MYDRV_DBG(1, "driver loaded, debug_level=%d\n", debug_level);
    MYDRV_DBG(2, "data path monitoring active\n");
    MYDRV_DBG(3, "full trace mode – expect high log volume\n");

    return 0;
}

static void __exit mydrv_exit(void)
{
    MYDRV_DBG(1, "driver unloaded\n");
}

module_init(mydrv_init);
module_exit(mydrv_exit);

The MYDRV_DBG macro keeps the code clean — you do not scatter if (debug_level >= X) checks everywhere. The macro is a zero-overhead wrapper when the compiler can see that debug_level is 0 and the condition is always false.

Making Module Parameters Persistent with modprobe.d

When you use insmod, parameters are one-time. When the system reboots or the module is reloaded by modprobe, it goes back to defaults. For production systems where you always want a specific debug level or device name, use the /etc/modprobe.d/ directory.

Create a file named after your module:

# Create /etc/modprobe.d/mydrv.conf
sudo nano /etc/modprobe.d/mydrv.conf

Add the options line:

# /etc/modprobe.d/mydrv.conf
# Set debug_level to 1 on every load, and device_name to eth_primary
options mydrv debug_level=1 device_name=eth_primary

Now every time modprobe mydrv runs (including at boot), it automatically applies these parameters. This is how real embedded Linux products are configured — no source changes, no recompilation, just a config file.

Robust Parameter Validation in module_init()

The kernel enforces type checking but not value range checking. If your driver expects debug_level to be between 0 and 3 and a user passes 999, the kernel happily accepts it. Your init function must catch this.

The right approach is to check every parameter at the very start of module_init() before doing anything else. If a parameter is invalid, print a clear error message and return -EINVAL:

static int __init validated_init(void)
{
    /* Validate debug_level range */
    if (debug_level < 0 || debug_level > 3) {
        pr_err("mydrv: invalid debug_level=%d (valid: 0-3)\n", debug_level);
        return -EINVAL;
    }

    /* Validate string parameter is not empty */
    if (!device_name || device_name[0] == '\0') {
        pr_err("mydrv: device_name cannot be empty\n");
        return -EINVAL;
    }

    /* Validate array count if using module_param_array */
    if (num_ports == 0) {
        pr_warn("mydrv: no ports specified, using defaults\n");
        /* ... set up defaults ... */
    } else if (num_ports > MAX_PORTS) {
        pr_err("mydrv: too many ports: %d (max %d)\n",
               num_ports, MAX_PORTS);
        return -EINVAL;
    }

    pr_info("mydrv: parameters validated OK\n");
    return 0;
}

Returning -EINVAL from module_init() causes insmod to report an error and the module is not loaded. The user sees:

insmod: ERROR: could not insert module mydrv.ko: Invalid argument

And dmesg shows your specific error message, which tells them exactly what went wrong.

Complete Driver Parameter Template for Linux 6.x

Here is a production-ready skeleton that combines everything covered in both parts of this tutorial. Use this as your starting point for any real device driver that needs runtime configuration.

// File: driver_template.c
// Complete module parameter template for Linux 6.x
// EmbeddedPathashala – Free Linux Device Drivers Course
//
// Covers:
//   - Integer parameter with range validation
//   - String parameter
//   - Boolean flag
//   - Array parameter for multi-instance support
//   - sysfs exposure with correct permissions
//   - modprobe.d compatible
//   - checkpatch.pl compliant

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

MODULE_LICENSE("GPL");
MODULE_AUTHOR("YourName <you@email.com>");
MODULE_DESCRIPTION("Device driver template with module parameters");
MODULE_VERSION("1.0");

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

#define MAX_INSTANCES  4

static int debug_level;
module_param(debug_level, int, 0660);
MODULE_PARM_DESC(debug_level, "Debug level 0-3 (default: 0)");

static char *drv_label = "mydrv0";
module_param(drv_label, charp, 0444);
MODULE_PARM_DESC(drv_label, "Driver label string (default: mydrv0)");

static bool loopback_mode;
module_param(loopback_mode, bool, 0660);
MODULE_PARM_DESC(loopback_mode, "Enable loopback test mode (default: N)");

static unsigned int irq_list[MAX_INSTANCES];
static int irq_count;
module_param_array(irq_list, uint, &irq_count, 0444);
MODULE_PARM_DESC(irq_list, "IRQ numbers for each instance (comma-separated)");

/* ------ Debug helper ------ */
#define DRV_DBG(lvl, fmt, ...)                              \
    do {                                                    \
        if (debug_level >= (lvl))                           \
            pr_info("mydrv: " fmt, ##__VA_ARGS__);         \
    } while (0)

/* ------ Validation ------ */
static int validate_params(void)
{
    if (debug_level < 0 || debug_level > 3) {
        pr_err("mydrv: debug_level must be 0-3\n");
        return -EINVAL;
    }
    if (!drv_label || strlen(drv_label) == 0) {
        pr_err("mydrv: drv_label cannot be empty\n");
        return -EINVAL;
    }
    if (irq_count > MAX_INSTANCES) {
        pr_err("mydrv: too many IRQs (max %d)\n", MAX_INSTANCES);
        return -EINVAL;
    }
    return 0;
}

/* ------ Init ------ */
static int __init drv_init(void)
{
    int ret, i;

    ret = validate_params();
    if (ret)
        return ret;

    DRV_DBG(1, "loaded label=%s debug=%d loopback=%d irqs=%d\n",
            drv_label, debug_level, loopback_mode, irq_count);

    if (loopback_mode)
        DRV_DBG(1, "loopback mode active – TX loops back to RX\n");

    for (i = 0; i < irq_count; i++)
        DRV_DBG(2, "instance[%d]: IRQ=%u\n", i, irq_list[i]);

    return 0;
}

/* ------ Exit ------ */
static void __exit drv_exit(void)
{
    DRV_DBG(1, "unloaded\n");
}

module_init(drv_init);
module_exit(drv_exit);

Real-World Use Cases – Where Module Parameters Are Used in Linux Drivers

Module parameters are not just a learning exercise. The mainline Linux kernel uses them extensively in real drivers:

Comparison: module_param() vs module_param_array() vs Sysfs Custom Attribute

Feature	module_param()	module_param_array()	Custom sysfs attribute
Values per parameter	One	Multiple (up to array size)	Anything you write
Set at load time	Yes	Yes	No (after load only)
Runtime modification	Yes (if perm != 0)	Yes (if perm != 0)	Yes (full control)
Code complexity	Very low	Low	High (manual store/show)
Type validation	Automatic (basic)	Automatic (basic)	Manual (you implement it)
modprobe.d support	Yes	Yes	No
Best for	Simple scalar config	Multi-instance config	Complex runtime state

Frequently Asked Questions