Ytdyklly

I recently installed a vendor supplied embedded linux onto a hardware device. When I ran lsmod on the device command line the response was empty. I was lead to believe that this means that the drivers for the hardware running on the device had been built into the kernel rather than as .ko files. My question is this: how does this process happen?

Is support for popular hardware gradually integrated into the kernel in subsequent versions thus replacing the .ko files? Is the .ko file simply used to support new hardware that doesn't have kernel integrated driver support at the time of release? In my limited knowledge I thought that all hardware drivers were of the form of .ko files but clearly this is wrong.

I am slightly confused by the whole process and would be grateful for clarification as I have a feeling that I may be looking at the situation the wrong way.

Core drivers that are considered critical to the loading of the kernel are usually built into the kernel, while other hardware drivers, etc. are built as modules or .ko files.

The .ko modules are usually stored under the /lib directory on your root partition. To use any of these, the kernel must first be able to detect and access the underlying storage device and then access its filesystem. So it's safe to assume that a kernel without SATA/SCSI and ext2/3/4 support built-into it won't really boot ;)

You can choose to switch most built-in kernel drivers into module form. The Ubuntu kernel team decides whether to modify the Linux kernel team's default configuration and include/exclude additional built-in drivers for the stock kernel images you download.

If you build your own kernel, you can do the same:

• In the above screenshot, the * indicates a built-in driver, while M indicates a module.


• Loopback device support, which is often essential to booting a system, is built-in by default.


• The low-speed USB driver (USB 1.0) is also built-in by default to allow you to boot off a USB stick, but here I have changed it into a module.

When compiling a kernel, you get to configure which components are installed. Not only that, but you get to chose whether or not they are built into the kernel or if they are a module.

For example, many people use the ext2 filesystem on their /boot partition. Because of this, the kernel must be able to read ext2 filesystems at boot time. In order to accomplish this, the ext2 module is built into the kernel itself.

Now, imagine the quantity of modules available. It wouldn't make sense to have them all built into your kernel, would it? This is why you can build these as separate .ko modules and load them at will.

These depends on how you have configured your build of the linux kernel.

Within a compilation process you usually can:

• compile the kernel with or without module support ( often it comes with module support )


• compile a driver as module or as a built-in piece of software right into the kernel

to understand what a .ko file is for https://stackoverflow.com/questions/10476990/difference-between-o-and-ko-file

The reason why you have an empty output on lsmod is because you have a monolithic kernel.

A quick way for listing all your modules ( if they are present ) is by running this command

find /lib/modules/*/ -type f -iname '*.ko' | less

notice the use of less, you can use every pager that you want or redirect the output where you want to.

See the contents of file /lib/modules/$(uname -r)/modules.builtin

e.g. to search for a specific module

grep <module> /lib/modules/$(uname -r)/modules.builtin

Documentation/kbuild/kbuild.txt

modules.builtin

--------------------------------------------------

This file lists all modules that are built into the kernel. This is used

by modprobe to not fail when trying to load something builtin.

ls /sys/module

seems to contain all built-in and external modules.

But it also appears to contain some entries which are not actually modules: https://unix.stackexchange.com/questions/225706/are-modules-listed-under-sys-module-all-the-loaded-modules

TODO: read the source and understand more precisely what gets put there.

The advantage of this method is that you don't rely on being able to find the kernel config under /boot or /proc/config.gz.