Kernel modules - who loads them?

[cv007]

I use microcore for a simple specific task which only needs to be able to change a file on an ntfs partition.  I grab vmlinuz + core.gz from the downloads, extract and modify the core.gz cpio archive, repack it, make hybrid iso, write it to a usb flash drive and I'm in business. I remove quite a bit of stuff from core.gz, and end up with about a 6MB iso file (takes about 15 seconds total to boot and do what I need to do).

I have been using this for quite some time, and have learned quite a bit while modifying it for my needs.

Recently, I ran into a problem on a certain pc where the usb keyboard (only usb ports on pc) would not work after it booted up. After some troubleshooting (a little difficult without a functioning keyboard), I discovered it needed the xhci-hcd module loaded before the keyboard would work (didn't matter which usb port used, without xhci-hcd loaded- no keyboard). Since I remove all modules when modifying core.gz, the simple fix was to keep module xhci-hcd.ko.gz, create an entry in the init script to insmod that module, which works fine.

My question- how does the kernel know whether to load a module or not?
(I used the standard core iso download to troubleshoot my problem- it loaded the xhci-hcd module 'automatically'. Is udevd,  which is started in tc-config, responsible for this?)

1. module already built into kernel- already loaded
2. specifically tell kernel to load it (insmod, modprobe, etc)
3.  ?  <---if not built in, and I don't tell it to load, how did it get loaded?

[frimical]

Hello cv007,

To answer quickly, udevd is launched very early on start-up, to listen to kernel events in order to execute related udev rules' instructions ( these are found in files in /etc/udev/rules.d/ ).
Have a look in this dir and check the contents of files with extension '.rules', where you can find many rules related to devices/connection, ( 'usb' too of course).

Regards
Frimical

[cv007]

Thanks.

So udevd (and its rules config files) is doing the job which in earlier linux times were probably handled with the use of an etc/modules.conf file (and whatever program or kernel made use of that file)?

While troubleshooting, I had first just left all the modules in place (/lib/modules/...), thinking that the kernel would go and find the required module, but that was not the case (I had removed all udev stuff, since I had not needed any modules up till now- so no udevd to help me). Had I left udev stuff in place (and rules), then the simple act of the module being available, and the running of udevd, the required module would have loaded without my help (if I understand this correctly).

In my case, just doing the insmod for the one module I need works fine.

So, I guess its
3. udevd + udev rules

[curaga]

1. Kernel tells udev device 035435436546546546576 was attached.
2. Udev calls modprobe with that as an argument.
3. Modprobe uses modules.alias and modules.dep to load the correct modules.

[cv007]

Thanks.