On a Linux host, how do you make a kernel module parameter — for example an option on a network driver — take effect every time that module is loaded, and how do you read back the value a loaded module is currently using?

## What a module parameter is A module parameter is a variable the module author explicitly exported as tunable, with a type and a permission mask. It is the module's own configuration surface — how many receive queues to allocate, whether to enable a workaround for buggy hardware, a debug verbosity level. Unlike a sysctl, it is not a general kernel knob; it belongs to that one module and exists only while the module is loaded or, for built-in code, for the life of the boot. Discover them first, always: ```bash modinfo -p e1000e # parameter name, type and description, per module ``` If a name does not appear there, the module does not accept it — and passing an unknown parameter makes the load fail rather than being silently ignored. ## The three ways a value gets in **1. On the load command.** `modprobe <module> <param>=<value>` passes the value at initialisation. Because parameters are read when the module initialises, this does nothing to an already-loaded module: you would have to unload and reload it, with all the service impact that implies for a storage or network driver. **2. In /etc/modprobe.d.** A file ending in `.conf` in that directory containing: ``` options e1000e InterruptThrottleRate=3 ``` is read by `modprobe` on every load of that module. This is the persistent, correct answer, and crucially it also covers the loads you never type — the automatic load when the kernel discovers the hardware. Note that the vendor and the distribution also ship files there; the merged view of the whole directory is what applies, so a conflicting line elsewhere can override yours. **3. On the kernel command line.** The form `<module>.<param>=<value>` works whether the code is built into the kernel or loaded as a module. This is the *only* route for a parameter of a built-in driver, because there is no load event to hook. It is also the escape hatch when a bad parameter in `/etc/modprobe.d` prevents the machine booting. ## Reading the live value Every parameter whose permission mask is non-zero appears as a file: ```bash cat /sys/module/e1000e/parameters/InterruptThrottleRate ls -l /sys/module/e1000e/parameters/ ``` The file mode is the parameter's declared permission. A mode of `0444` means read-only: the author intended it to be set at load time only, and the kernel will reject a write even from root — the error is a permission failure, not a sysfs mount problem. A mode of `0644` means the module supports changing it live, though what "live" means is entirely up to the module: some re-read the variable on every operation, others cache it and your write has no visible effect until reload. Parameters declared with a permission of zero get no sysfs file at all and are invisible after load. ## The traps worth naming in an interview - **`insmod` does not read `/etc/modprobe.d`.** It is the raw insert; only `modprobe` implements the configuration layer. Anyone debugging "my options line is ignored" should check how the module is actually being loaded. - **The initramfs carries its own copy.** If the module is loaded before the root filesystem is available — a storage controller, sometimes a network driver on a network-booted host — the copy of the configuration inside the initramfs is what applies. Editing `/etc/modprobe.d` and rebooting changes nothing until the initramfs is regenerated with the distribution's tool. - **Built-in code cannot take load-time parameters at all**, for the obvious reason. If `modinfo` shows a parameter but there is no `/sys/module/<name>/parameters/` directory and the module is not in `lsmod`, check whether it was compiled in. - **A wrong value can be a boot failure.** A bad parameter makes the module fail to initialise; if that module is your only network interface or your disk controller, you have just lost the host. Test by unload/reload before you make it persistent, and know the kernel command-line override. ## Verifying, not assuming The complete loop is: `modinfo -p` to learn the name, write the `options` line, reload the module (or reboot, regenerating the initramfs if the module loads early), then read `/sys/module/<name>/parameters/<name>` to confirm the kernel actually took the value. Skipping the last step is how people end up believing a tuning change is in place when the file was never read.