During development, you usually use insmod to load a module and it should be given the path of the module to load:
$ insmod filename [module-options]
It is low-level form of module loading, that forms the base of other module loading methods, and is the one we will use in this book. On the other hand, there is modprobe, mostly used by sysadmins or in a production system. modprobe is a clever command that parses the modules.dep file in order to load dependencies first, prior to loading the given module. It automatically handles module dependencies, as a package manager does:
$ modprobe module-name
|Loads the module given as ‘insmod /path/to/module.ko’||Loads the module only in /lib/modules/$(uname -r). ‘modprobe /home/test/hello.ko’ will not work|
|Dependencies if present are not loaded||modprobe calculates dependencies, loads the dependencies and then the main module|
How modprobe calculates dependencies?
Modprobe depends on depmod tool to calculate dependencies. depmod calculates dependencies of all the modules present in /lib/modules/$(uname -r) folder, and places the dependency information in /lib/modules/$(uname -r)/modules.dep file
E.g. 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 case, eeprom_93cx6.ko, cfg80211.ko is loaded first and then adm8211.ko
Modules are loaded right to left and removed left to right. So while removing adm8211.ko is removed, then cfg80211.ko and finally eeprom_93cx6.ko. We can re-load the modules.dep file by running “depmod -a” command
insmod is a system administration command to load the module filename into the kernel. Simpler but less flexible than the modprobe command. Error messages from insmod may be vague, because the kernel performs module operations internally and therefore sends error information to the kernel log instead of standard output; see dmesg.
The information in the module.* files is used by the command modprobe to locate a module by name rather than the full path. modprobe has many other features which are described in the manual.
The module dependency information is also used by device managers, udev in particular. When new hardware is detected, for example a new USB device, the udevd daemon is alerted and passed the vendor, and product IDs are read from the hardware. udevd scans the module dependency files looking for a module that has registered those IDs. If one is found, it is loaded using modprobe.