If you restate the problem as "How can I run modinfo
on all (or some) modules and select some of the output for further use?", you could use this trick (I've left the commands I used to figure out how to get to the final result):
ls /lib/modules
ls /lib/modules/$(uname -r)
ls /lib/modules/$(uname -r)/kernel
find /lib/modules/$(uname -r)/kernel -type f -name '*.ko' -print
for i in $( !! ) ; do
for i in $( find /lib/modules/$(uname -r)/kernel -type f -name '*.ko' -print ) ; do
j=${i##.*/}
j=${j%%.ko}
echo $j
modinfo $i | egrep 'filename:|alias:'
echo ""
done
This trick can be used elsewhere, have fun!
First some history. In the earlier days of Linux, device drivers were indeed compiled directly into the kernel. In fact, it's possible still to compile drivers directly in and many kernels may still have some very common drivers included this way. The way it worked was the generic kernel shipped with the early distributions like SLS or Slackware had virtually every driver the kernel supported compiled directly into it so it would work on the widest possible variety of hardware possible. Even then, it wasn't possible to put them all in because some of them are mutually incompatible. Then, after you got your system installed, you would build your own kernel, carefully going through the configuration to make sure you included the correct drivers for everything your computer had. Sometimes you had to manually edit header files in the driver to include support for oddball hardware - an Ethernet card that used a particular chipset used that chipset's drivers, but sometimes there were funny ways it was implemented. Then you'd compile, install, and hopefully after a reboot you then had a custom kernel built for just your computer. Lean and optimized. In reality, you generally repeated this process several times including things you missed, adding support for a filesystem you forgot, or tweaking the settings in some way. Rinse and repeat.
Those days are, thankfully, long past. The kernel has, for a very long time, supported loadable modules. These are kernel drivers compiled so as to become a type of shared library that can be loaded or unloaded on demand. Now the way a kernel boots is you have the kernel file itself and a small compressed filesystem (look at initramfs on Wikipedia) that has in it all the kernel modules that kernel supports. The kernel loads, it finds its initial filesystem and then it can start loading all the drivers it needs.
That little bit of history is skipping a lot of work and sweat along the way. In between using all compiled-in drivers in one huge monolithic kernel and having a fully automated driver loading system we have today were all the steps along that path where we had modules that had to be explicitly loaded, semi-automatic loading for some, etc etc.
So, since modern kernels demand load the vast majority of the drivers they need, there are no significant amount of redundant hardware drivers taking up resources in the kernel of any modern Linux distribution.
Best Answer
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:
*
indicates a built-in driver, whileM
indicates a module.