What is Module and How it works

What is Module

Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system. Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.

modprobe doesn't communicate through netlink or sysfs (both features are younger than module loading), it calls the init_module system call.

Path

Modules are stored in /usr/lib/modules/kernel_release. You can use the command uname -r to get your current kernel release version.

Note: Module names often use underscores (_) or dashes (-); however, those symbols are interchangeable, both when using the modprobe command and in configuration files in 
/etc/modprobe.d/.

Commands 

To show what kernel modules are currently loaded:

$ lsmod

To show information about a module:

$ modinfo module_name

To list the options that are set for a loaded module:

$ systool -v -m module_name

To display the comprehensive configuration of all the modules:

$ modprobe -c | less

To display the configuration of a particular module:

$ modprobe -c | grep module_name

List the dependencies of a module (or alias), including the module itself:

$ modprobe --show-depends module_name

To load a module:

# modprobe module_name

To load a module by filename (i.e. one that is not installed in /lib/modules/$(uname -r)/):

# insmod filename [args]

To unload a module:

# modprobe -r module_name

Or, alternatively:

# rmmod module_name

The uevent message contains information about the device (example). This information contains registered vendor and model identification for devices connected to buses such as PCI and USB. Udev parses these events and constructs a fixed-form module name which it passes to modprobe. modprobe looks under /lib/modules/VERSION for a file called depmod.alias which is generated when the kernel is installed and that maps the fixed-form module names to actual driver module file names. See Are driver modules loaded and unloaded automatically? for more details about the process — that answer describes the earlier days when the kernel called modprobe directly, but the way modprobe and module aliases work hasn't changed.

modprobe loads a module by calling the init_module system call. It doesn't interact with sysfs in any way. When the module is loaded, the kernel creates an entry for it in /sys/module. Any entry that appears elsewhere in sysfs is up to the code in the module (e.g. a module with a driver for a type of USB devices will call some generic USB support code that adds an entry under /sys/bus/usb/drivers).

                   

When modprobe dynamically loads kernel module does that module (driver) then appear at /sys/bus/drivers directory ? Also does modprobe communicate back with the kernel through netlink socket ? Does it communicate back to sysfs ?           

Automatic module handling

Today, all necessary modules loading is handled automatically by udev, so if you do not need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any configuration file. However, there are cases where you might want to load an extra module during the boot process, or blacklist another one for your computer to function properly.

Kernel modules can be explicitly loaded during boot and are configured as a static list in files under /etc/modules-load.d/. Each configuration file is named in the style of /etc/modules-load.d/<program>.conf. Configuration files simply contain a list of kernel modules names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored.

/etc/modules-load.d/virtio-net.conf

# Load virtio-net.ko at boot

virtio-net

See modules-load.d(5) for more details.

Note: If you have upgraded your kernel but have not yet rebooted, modprobe will fail with no error message and exit with code 1, because the path /lib/modules/$(uname -r)/ no longer exists. Check manually if this path exists when modprobe failed to determine if this is the case.

Setting module options

To pass a parameter to a kernel module, you can pass them manually with modprobe or assure certain parameters are always applied using a modprobe configuration file or by using the kernel command line.

Manually at load time using modprobe

The basic way to pass parameters to a module is using the modprobe command. Parameters are specified on command line using simple key=value assignments:

# modprobe module_name parameter_name=parameter_value

Using files in /etc/modprobe.d/

Files in /etc/modprobe.d/ directory can be used to pass module settings to udev, which will use modprobe to manage the loading of the modules during system boot. Configuration files in this directory can have any name, given that they end with the .conf extension. The syntax is:

modprobe is a Linux program originally written by Rusty Russell and used to add a loadable kernel module (LKM) to the Linux kernel or to remove a LKM from the kernel. It is commonly used indirectly: udev relies upon modprobe to load drivers for automatically detected hardware.[citation needed]

The modprobe program offers more full-featured "Swiss-army-knife" features than the more basic insmod and rmmod utilities, with the following benefits:

an ability to make more intuitive decisions about which modules to load

an awareness of module dependencies, so that when requested to load a module, modprobe adds other required modules first

the resolution of recursive module dependencies as required

If invoked with no switches, the program by default adds/inserts/installs the named module into the kernel. Root privileges are typically required for these changes.

Any arguments appearing after the module name are passed to the kernel (in addition to any options listed in the configuration file).

In some versions of modprobe, the configuration file is called modprobe.conf, and in others the equivalent is the collection of files called <modulename> in the /etc/modprobe.d directory.

Features

The modprobe program also has more configuration features than other similar utilities. It is possible to define module aliases allowing for some automatic loading of modules. When the kernel requires a module, it actually runs modprobe to request it; however, the kernel has a description of only some module properties (for example, a device major number, or the number of a network protocol), and modprobe does the job of translating that to an actual module name via aliases.

This program also has the ability to run programs before or after loading or unloading a given module; for example, setting the mixer right after loading a sound card module, or uploading the firmware to a device immediately prior to enabling it. Although these actions must be implemented by external programs, modprobe takes care of synchronizing their execution with module loading/unloading.

Blacklist

There are cases where two or more modules both support the same devices, or a module invalidly claims to support a device: the blacklist keyword indicates that all of a particular module's internal aliases are to be ignored.

There are a couple of ways to blacklist a module, and depending on the method used to load it depends on where this is configured.

There are two ways to blacklist a module using modprobe, employing the modprobe.conf system, the first is to use its blacklisting system in /etc/modprobe.d/blacklist:

cat /etc/modprobe.d/blacklist

blacklist ieee1394

blacklist ohci1394

blacklist eth1394

blacklist sbp2

Alternately, you can modify /etc/modprobe.conf:

alias sub_module /dev/null

alias module_main /dev/null

options module_main needed_option=0