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.

3 Answers
3

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.

So on a kernel configured without module support (as mine appears to be) I would be unable to install any drivers in the form of .ko files to use additional hardware?
–
mathematician1975Jul 13 '12 at 23:13

yes, basically you have to recompile it from the source, if you want to edit and/or add drivers you have to rebuild it, maybe just use the same .config file and modify it as you need.
–
user827992Jul 13 '12 at 23:15

So in order to do this I would need to get the kernel source from the vendor, compile it myself with the correct modifications to the .config file then I will be good to install other drivers?
–
mathematician1975Jul 13 '12 at 23:25

depends, if he used a vanilla kernel ( without nothing more than the original source code ) you are ok with just the .config and you can reproduce the same kernel just with your pc, however if he used a vanilla kernel + some patches or modifications you need this extra informations, a custom Makefile could be also considered as a relevant variable as any other modifications to the standard toolchain and in general to the standard build process.
–
user827992Jul 13 '12 at 23:31