Hi there ! 🙂
I want to share with you my progress with Linux Kernel Backports project.
As I was saying in the previous article, the task is to extend ‘make localmodconfig’ option from Linux Kernel for backported drivers.
Currently, ‘make localmodconfig’ creates a configuration file based on the output of lsmod command, namely creates a configuration that contains all modules inserted in the kernel of the machine which runs lsmod. For example, you can run lsmod on a target machine, save its output and then create new kernel for the target machine.
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
host$ make LSMOD=/tmp/mylsmod localmodconfig
You may want a different kernel version (drivers are updated, bugs resolved etc.) or want more or less functionalities than the original kernel but keeping the required modules.
There are two shortcomings of this method:
- lsmod retrieves the modules that are present in the kernel, not necessary the ones that are actually used.
- We may run lsmod on a machine with a particular hardware functionality and an older kernel version X that does not support that functionality. Consequently, there will be no module retrieved by lsmod that covers that hardware need. If, in the meantime, the Linux Kernel was added a driver for that functionality and then it was backported to the kernel version X we could not benefit from its support using ‘make localmodconfig’ although it’s available for us.
I intend to solve this problems with this project.
Clearly relying on the output of lsmod is problematic so let’s see where the driver information can come from:
The first idea is to use hardware interrogation tools such as lspci, lsusb etc to detect the actual devices connected to different interfaces and the drivers that support them. I have made a research on this tools and I have created a spreadsheet summarizing all encountered tools and the exact commands to return driver information. This is a good approach but some encountered tools do not provide driver information at all and, moreover, there is no guarantee that there exists a tool for each interface.
A most suitable approach is using a generic tools such as systemd. Does it sound familiar ?
Well, if you use a wide-spread Linux distribution, you clearly use systemd. Surely the next screen is familiar to you:
Systemd is the init system used to bootstrap the operating system’s user space and all its processes. Moreover, systemd is a system and service manager, a software platform and provides various interfaces that expose functionalities provided by the kernel. Thus, systemd is not just the the init daemon but also refers to the entire software bundle around it, which includes the daemons journald, logind and networkd, and many other low-level components. The following images shows an example of systemd architecture used by the operating system Tizen (source: Wikipedia):
Relevant for my project is the systemd utilitary udev which inspects connected devices:
udevadm info -e
The previous command lists all connected devices along with the other information about them. Within this other information the driver name is included. It would seem like exactly what I need. Further, I extended streamline_config.pl (the main script that implements ‘make localmodconfig’) to call and use the output of the previous command instead of the output of lsmod. Although the script generated a configuration similar with the one from lsmod, OS booting fails with the following output:
There are many guesses for this error: there may be some non-hardware devices not managed by udevadm but required at boot time, or maybe their driver name was not shown in the output of udevadm or even the SAT resolving algorithm from streamline_config.pl fails for this particular case. I will make a closer investigation and keep you updated.
Until next time ! 😉