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:

enter image description here

  • 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.
  • Thanks that helps a lot. I guess I will get a better understanding of this when I eventually do a kernel build from scratch for myself. – mathematician1975 Jul 13 '12 at 23:11

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.

  • 1
    Yes your last paragraph is what motivated my question to be honest. Thanks for the answer – mathematician1975 Jul 13 '12 at 23:11

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.

  • 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? – mathematician1975 Jul 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. – user827992 Jul 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? – mathematician1975 Jul 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. – user827992 Jul 13 '12 at 23:31
  • It's my experience that modules are disabled for embedded Linux, for speed and size reasons, and that the kernels for such devices often contain out-of-tree drivers and are built on some random employee's PC without benefit of source control. Good luck with that. – Stephen M. Webb Oct 28 '16 at 16:43

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


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.
  • ??? Not sure what the the OP is supposed to do. Is he supposed to run the first line in the terminal? This could be the answer, but would you please elaborate a bit? – anonymous2 Sep 14 '16 at 19:41
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.