I know modprobe can be used to load modules, but how does it decide
which modules to load?
When the kernel needs a feature that is not resident in the kernel, the kernel module daemon
modprobe to load the module in.
modprobe is passed a string in one of two forms.
- A module name like softdog or ppp.
- A more generic identifier like char-major-10-30
So, let me explain what I found in my system rather than pasting from the link.
cat /proc/modules - This command lists what modules are loaded and the list is a pretty huge list.
Now, during the start up of the system, as I had already mentioned, the
kmod daemon executes the
modprobe to load the modules. We could specify the module to be loaded in either of 2 ways as already discussed. If we have specified a generic identifier, it will look for that entry in
/etc/modprobe.conf for alias. So, in my
/etc/modprobe.conf, I have an alias as below.
alias eth0 tg3
So, I ran the below command to check what is tg3 in my system.
-bash-3.2$ cat /proc/modules | grep tg3
tg3 139225 0 - Live 0xf8bd1000
modprobe looks through the file
/lib/modules/version/modules.dep, to see if other modules must be loaded before the requested module may be loaded. This file is created by
depmod -a and contains module dependencies.
insmod to first load any prerequisite modules into the kernel, and then the requested module.
/lib/modules/version/, the standard directory for modules.
insmod is intended to be fairly dumb about the location of modules, whereas
modprobe is aware of the default location of modules, knows how to figure out the dependencies and load the modules in the right order.
But how is the new hardware detected?
These rings are created by CPU and not by OS. Any OS kernel operates in Ring 0 which is most privileged level and can communicate directly to the hardware and the CPU. Rings 1 and 2 are commonly used for device drivers. And ring 3 is used for user-space applications (media players, web servers and anything else user can communicate to directly). Device drivers are a “bridge” between user-space applications and hardware.
Linux kernel constantly scans all your computer bus’es for any changes and new hardware. Once any change on any bus is detected magic begins.
- EXPORT HARDWARE INFORMATION TO USERSPACE (SYSFS)
- *NOTIFY USERSPACE TOOLS THAT HARDWARE IS AVAILABLE (UEVENT AND UDEVD)
- Yeah, your assumption is correct. udev has something to do with the magic :)*
- PROCESS UEVENTS, MATCH THEM AGAINST RULES IN /ETC/UDEV/RULES.D/ AND
POPULATE /DEV DIRECTORY (UDEVD AND UDEV)
- LOAD DEVICE DRIVERS (UDEV, MODPROBLE)
- NOTIFY USERSPACE APPLICATIONS (THROUGH D-BUS)
Udevd is just a daemon standing in between the Kernel and all the udev
system and perform some important functions (I’ll mention them later).
The udev daemon (udevd) is started at startup then reads and parses
all the rules found in /etc/udev/rules.d/ and keep these rules in
memory (udev database) for further usage by udev. Later udevd start to
listen on the netlink for uevents comming from Kernel driver core.