Feature Suggestion: kernel driver exclusion via hardware census #31
Description
(This is related to issue #29, pertaining to the contents of /boot/firmware in resultant builds; this issue refers to driver modules that come pre-included with kernel images that are typically installed to /boot/firmware.)
There are some 1,830+ drivers that now accompany the Linux kernel image in wider circulation, amounting to nearly 20MB. It can be largely-argued, especially in an embedded or locked-down setting, that the majority of them will never get loaded during a single boot-to-shutdown cycle.
I would like to put forward a suggestion of allowing the exclusion of kernel drivers by performing a "hardware census"; that is, for the purpose of piecing together an affirmative list of actively-loaded kernel drivers, and to expunge those that are not loaded.
I've pieced together a pseudo-list of tasks that could achieve this end and reduce the resultant size of pi-gen-micro images.
Identifying what is actually being used...
One way I can see this being a possibility, is that the user/owner first configures their Raspberry Pi, say, running the latest Raspberry Pi OS non-graphical install, so that it is currently perfectly-performing all the required functionality, as well as:
- editing
config.txtin/boot/firmwareor viaraspi-configas-necessary - having all external/required peripherals connected at the same time
Then, via lsmod, making sure udev has settled beforehand, take a snapshot of the currently-loaded driver list, and parse it to a simple list. I would suggest adding a "press any key" followed by a time delay prior to invoking the command, so there is a window to detach any hardware, such as displays, mice and keyboards the user doesn't want included in the scan.
Then at this point, it may be worth also reading, being on by-default, for drivers mentioned as "soft dependencies" in modules.softdep of the loaded drivers identified before and to also include those on the list as well and any dependencies to those. It may be also constructive to also have a manual-inclusion list.
We should now have the complete list of required modules/drivers.
Filtering the files themselves (and shortening the paths to them)
Using kernel version 6.6.74-v8+ as a basis, we could now recursively scan the directory...
/lib/modules/6.6.74-v8+/...
... for all drivers (e.g. *.ko.xz).
On each module the search finds, we can scan its name against our list, and if the name is not on that list... delete it. If it is on the list, bring/move it forward up to the top of of the driver folder directory tree; for example...
/lib/modules/6.6.74-v8+/kernel/drivers/firmware/rp1.ko.xz
...would become...
/lib/modules/6.6.74-v8+/rp1.ko.xz
This should work without issue, as it has never been the case where there are two drivers with the exact same name, and placement within the driver directory tree has no bearing so long as the "modules" files in the root of said directory does correctly point to them.
Rebuilding the modules.* trees and final result
Now that we would have the files themselves needed, we can purge all the (empty) sub-directories. Next, we would need to rebuild the module-mapping lists; depmod is the tool that can do this. Once this is compelte, we'll have ourselves a brand new subset of drivers we know for-sure that will get loaded and mapping files that correctly reference them and that are significantly smaller in-size, namely:
- There are fewer modules and mapping entries altogether
- The mapping paths to each module are significantly shorter and eliminates repetition of those paths (as paths are relative to the root of the modules folder, eg.
/lib/modules/6.6.74-v8+, src: depmod(8))
Conclusion
I can't give any accurate estimates as to the savings this will achieve, as it will vary from one configuration scenario to the next, but we could be looking in the ballpark of least 10MB here.