Difference between Insmod and Modprobe?

In this article, we will discuss the insmod and modprobe and their differences.

Insmod :

The name of the kernel module's file and any module-specific parameters that the module accepts upon insertion is sent to insmod as arguments.

Modules are inserted into the kernel using the insmod command on Linux systems. As a way to increase the functionality of the kernel, Linux's operating system enables users to load kernel modules at runtime.

As the actual job of connecting the module is done in the kernel itself, the only error messages that insmod may produce are very general ones. The best way to observe errors is through dmesg because any errors issued are produced by the kernel.

Typically, insmod is used to load a module when developing, and it needs to be provided with the path of the module to load:

Modprobe :

A loadable kernel module can be added to the Linux kernel or removed from the kernel using the modprobe tool, which was created by Rusty Russell. It is frequently used in an indirect manner since udev uses modprobe to load drivers for hardware that is automatically recognised.

The primary module and the dependent module are loaded via modprobe. In addition to loading the desired module, insmod also loads any additional modules that it detects as being necessary. However, in order to load custom modules from the current directory, you will still require insmod since modprobe only searches the loaded module directories that come standard. In contrast, modprobe is typically used by sysadmins or in a production system. Modprobe is an intelligent command that analyses the modules.dep file to load dependencies first before loading the specified module. In the same way as a package manager does, it automatically manages module dependencies:

Difference between insmod and modprobe?

How does modprobe figure out dependencies?

Modprobe uses the depmod utility to determine dependencies. Depmod determines the dependencies for each module in the /lib/modules/$(uname -r) folder and stores the information in the /lib/modules/$(uname -r)/modules.dep file

For instance,

kernel/drivers/net/wireless/admtek/adm8211.ko: kernel/net/mac80211/mac80211.ko kernel/net/wireless/cfg80211.ko kernel/drivers/misc/eeprom/eeprom_93cx6.ko

In this instance, eeprom_93cx6.ko, cfg80211.ko is loaded first and then adm8211.ko

Modules are deleted left to right and loaded right to left. As a result, while removing adm8211.ko is removed, then cfg80211.ko and finally eeprom_93cx6.ko

The modules.dep file can be loaded again by running "depmod -a" command

Summary

The module filename is loaded into the kernel using the system administration command insmod. It is simpler but less adaptable than the modprobe command. Because the kernel executes module operations internally and instead of standard output, sends error data to the kernel log. The error messages may be ambiguous from insmod.

The information in the module.* files is utilised using the command modprobe. Users may find a module by name instead of using the entire path. There are numerous additional functions of modprobe that are detailed in the handbook.

Device managers, udev in particular, utilise the information about module dependencies. The vendor alerts the udevd daemon and passes it when new hardware, such as a new USB device, is found. Product IDs are then read from the hardware and passed to the vendor. The module dependency files are searched by udevd for the module that registered those IDs. If any ID is discovered, it is loaded using modprobe.