All you need is a binary Linux kernel

By: Carsten Emde

Read more why and when this is true

Souvenir of yesterday

In the good old days when only a few computer boards were released per year and mainline kernel support was available for most of them, it was an excellent idea to save the current kernel configuration in the binary kernel. This made it possible to rebuild an identical binary kernel from the vanilla kernel sources at any time. The goal was (and still is), of course, not to simply build an identical binary kernel but to use it as a base for future work on this particular implementation.

Modern times

In modern times when myriads of (mostly ARM based) computer boards are swamping the market most of which require a large patchset that often is difficult to obtain, the saved kernel configuration file is nearly useless. If a patchset cannot be obtained with reasonable effort, the board vendor is, of course, losing his kernel license, but this is another story we will cover later.

The solution

A Linux kernel patch is now available that provides a simple mechanism to store the respective patchset in the binary kernel in a very similar way as it is done with the kernel configuration file. The archive of the patch queue can be extracted with a script from the kernel image, but it is also possible to get it from a running kernel through the virtual proc file /proc/patches.tar.gz.

How does it look like?

A simple command such as

tar ztvf /proc/patchset.tar.gz 
-rw-r--r-- root/root      2165 2013-01-11 17:49 patches/your.patch

will give you access to the patches, isn't that a cool feature?

Will this (further) bloat the kernel?

Yes and no. Yes, because people may use this term also with respect to the increase in the size of the binary kernel; its amount obviously depends on the number of patches. If, however, this helps to convince vendors to more and earlier submit their patches to mainline Linux and, thus, reduce the size of the off-tree patches – even better! No, since the term of a "bloated kernel" refers to the sheer amount of (more or less) obscure code, rather than to the number of kBytes per se. In a normal case where only a few patches are applied, the increase in size is less than 20 kByte and, thus, neglectable. But even the heaviest patched board (of course an ARM board that is on the market since two years, but still not usable with a mainline kernel) will not suffer from more than about 5% extra kernel size.

To reproduce the source tree that was used for a particular kernel the following command sequence will do the job (this example assumes that, in addition to CONFIG_IKPATCHSET, the CONFIG_IKPATCHSET_PROC configuration item was selected to access the patchset via the /proc filesystem):

tar zxf /proc/patchset.tar.gz baseversion
major=`cut -d. -f1 baseversion`
urldir=http://www.kernel.org/pub/linux/kernel/v$major.x
dir=linux-`cat baseversion`
archive=$dir.tar.xz
wget $urldir/$archive
tar Jxf $archive
cd $dir
tar zxf /proc/patchset.tar.gz
quilt push -a
zcat /proc/config.gz >.config

When this script has finished the kernel source tree is ready and waiting for someone to type make.

Would this fulfill the disclosure obligations of the GPL?

Not really, since the kernel.org web site may be down for a certain time (huh?), and during this outage period the vendor of the product that contains a kernel with the above mechanism would be in breach of the GPL, if simply referring to the patchset in the kernel. In addition, the kernel's GPLv2 does not explicitly allow the sources to be provided using a network server. If, however, the related base version of the mainline kernel source is delivered along with the product according to sec. 3a GPLv2, the new feature makes even more sense:

• Simply provide an easy 1:1 copy of the base version mainline kernel
• The patches automatically correspond to the binary kernel

In any case, please consult a lawyer to get a professional opinion on all of this should you plan to achieve GPL compliance this way.

A little problem still ...

For the time being, the patch is not available in mainline Linux - in consequence, it helps others when using our kernels because OSADL QA farm systems routinely carry their patches, if any. Unfortunately, it does not help us to solve problems we have with horribly patched third party kernels when we really need the source tree to fix them – unless we convince everybody to use the new feature and store their patches in the kernel.

Here are good news with respect to patched QA Farm kernels

The circled new button was added to the end of the patch list of certain OSADL QA Farm systems. The patch lists are located at the bottom of the system profiles. When clicking on the button, an individual download and patch script will be generated on the fly and made available to be saved locally. Use this script to create a kernel source tree on your disk that will result, if compiled with the same compiler and version, in an identical binary kernel as the one on this particular farm system. Wouldn't it be good if all kernels were this way? Well, with the new kernel feature they could ...

---