Kernel .patches support
PATCH 1/1 Kernel .patches support
Hi everybody,
every time I apply a patch to my kernel tree I (or my scripts) make an
echo $PATCHNAME $PATCHVERSION >> .patches
This patch makes the file accessible via /proc/patches.gz. I think this can be handy if you want to know what patches you (or your distributor) applied to your running kernel...
Most of the code is copy & past from CONFIG_IKCONFIG[_PROC].
Let me know what you think.
Regards,
Signature · 1 line
Christian
include/linux/patches.h +6 -0
@@ -0,0 +1,6 @@ +#ifndef _LINUX_PATCHES_H +#define _LINUX_PATCHES_H + +#include <linux/autoconf.h> + +#endif
init/Kconfig +19 -0
@@ -226,6 +226,25 @@ This option enables access to the kernel configuration file through /proc/config.gz. +config IKPATCHES + bool "Kernel .patches support" + ---help--- + This option enables the complete Linux kernel ".patches" file + contents to be saved in the kernel. It provides documentation + of which kernel patches are applied in a running kernel. This + information can be extracted from the kernel image file with + the script scripts/extract-ikpatches and used as input to + rebuild the current kernel or to build another kernel. + It can also be extracted from a running kernel by reading + /proc/patches.gz if enabled (below). + +config IKPATCHES_PROC + bool "Enable access to .patches through /proc/patches.gz" + depends on IKPATCHES && PROC_FS + ---help--- + This option enables access to the kernel patches file + through /proc/patches.gz. + config CPUSETS bool "Cpuset support" depends on SMP
kernel/Makefile +16 -0
@@ -21,6 +21,8 @@ obj-$(CONFIG_CPUSETS) += cpuset.o obj-$(CONFIG_IKCONFIG) += configs.o obj-$(CONFIG_IKCONFIG_PROC) += configs.o +obj-$(CONFIG_IKPATCHES) += patches.o +obj-$(CONFIG_IKPATCHES_PROC) += patches.o obj-$(CONFIG_STOP_MACHINE) += stop_machine.o obj-$(CONFIG_AUDIT) += audit.o obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
@@ -52,3 +54,17 @@ targets += config_data.h $(obj)/config_data.h: $(obj)/config_data.gz FORCE $(call if_changed,ikconfiggz) + +$(obj)/patches.o: $(obj)/patches_data.h + +# patches_data.h contains the same information as ikpatches.h but gzipped. +# Info from patches_data can be extracted from /proc/patches* +targets += patches_data.gz +$(obj)/patches_data.gz: .patches FORCE + $(call if_changed,gzip) + +quiet_cmd_ikpatchesgz = IKPTC $@ + cmd_ikpatchesgz = (echo "static const char kernel_patches_data[] = MAGIC_START"; cat $< | scripts/bin2c; echo "MAGIC_END;") > $@ +targets += patches_data.h +$(obj)/patches_data.h: $(obj)/patches_data.gz FORCE + $(call if_changed,ikpatchesgz)
kernel/patches.c +115 -0
115 lines not on this page · raw message
Quoted 7 lines · Christian Hesse
every time I apply a patch to my kernel tree I (or my scripts) make an
echo $PATCHNAME $PATCHVERSION >> .patches
This patch makes the file accessible via
/proc/patches.gz. I think this can be handy if you want to know what patches you (or your distributor) applied to your running kernel...
I haven't looked at the implementation, but I love the functionality.
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 1-866-677-4546
Quoted 1 line · Christian Hesse
Most of the code is copy & past from CONFIG_IKCONFIG[_PROC].
I haven't looked, but would it be possible to share this code instead of copying it ?
Signature · 4 lines
Ian Campbell Waking a person unnecessarily should not be considered a capital crime. For a first offense, that is.
Quoted 11 lines · Christian Hesse
Hi everybody,
every time I apply a patch to my kernel tree I (or my scripts) make an
echo $PATCHNAME $PATCHVERSION >> .patches
This patch makes the file accessible via
/proc/patches.gz. I think this can be handy if you want to know what patches you (or your distributor) applied to your running kernel...
...
Let me know what you think.
To be honest, I'm not a fan of it.
If e.g. looking at a Debian kernel source that has 289 different patches with names like tty-locking-fixes7 applied, you'll see that this often won't give you much valuable information.
You'd need an uniform naming convention for patches across distributions, and I don't think such things are worth the effort.
include/linux/patches.h line 6
Quoted 13 lines
Regards,
Christianinclude/linux/patches.h +6
-0@@ -0,0 +1,6 @@ +#ifndef _LINUX_PATCHES_H +#define _LINUX_PATCHES_H + +#include <linux/autoconf.h> + +#endif
What do you need this file for?
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 13 lines · Adrian Bunk
include/linux/patches.h 2005-06-23 23:10:15.278685000 +0200 line 6
Quoted 10 lines · Christian Hesse
include/linux/patches.h 2005-06-23 23:10:15.278685000 +0200 renamed from include/linux/patches.h 1970-01-01 01:00:00.000000000 +0100 +6
-0@@ -0,0 +1,6 @@ +#ifndef _LINUX_PATCHES_H +#define _LINUX_PATCHES_H + +#include <linux/autoconf.h> + +#endifWhat do you need this file for?
I think it should be <linux/config.h>.
Signature · 2 lines
Coywolf Qi Hunt http://ahbl.org/~coywolf/
Quoted 16 lines · Coywolf Qi Hunt
Quoted 14 lines · Adrian Bunk
Review
Quoted 11 lines · Christian Hesse
---
linux-2.6.12+/include/linux/patches.h1970-01-01
01:00:00.000000000 +0100 +++linux-2.6.12+-patches/include/linux/patches.h2005-06-23
23:10:15.278685000 +0200 @@ -0,0 +1,6 @@(quoted diff) +6
-0+#ifndef _LINUX_PATCHES_H +#define _LINUX_PATCHES_H + +#include <linux/autoconf.h> + +#endifWhat do you need this file for?
Quoted 1 line
I think it should be <
linux/config.h>.
Stupid me. It was too late last night. :)
You're right, I removed the file and included linux/config.h in kernel/patches.c.
Signature · 1 line
Christian
init/Kconfig +19 -0
@@ -226,6 +226,25 @@ This option enables access to the kernel configuration file through /proc/config.gz. +config IKPATCHES + bool "Kernel .patches support" + ---help--- + This option enables the complete Linux kernel ".patches" file + contents to be saved in the kernel. It provides documentation + of which kernel patches are applied in a running kernel. This + information can be extracted from the kernel image file with + the script scripts/extract-ikpatches and used as input to + rebuild the current kernel or to build another kernel. + It can also be extracted from a running kernel by reading + /proc/patches.gz if enabled (below). + +config IKPATCHES_PROC + bool "Enable access to .patches through /proc/patches.gz" + depends on IKPATCHES && PROC_FS + ---help--- + This option enables access to the kernel patches file + through /proc/patches.gz. + config CPUSETS bool "Cpuset support" depends on SMP
kernel/Makefile +16 -0
@@ -21,6 +21,8 @@ obj-$(CONFIG_CPUSETS) += cpuset.o obj-$(CONFIG_IKCONFIG) += configs.o obj-$(CONFIG_IKCONFIG_PROC) += configs.o +obj-$(CONFIG_IKPATCHES) += patches.o +obj-$(CONFIG_IKPATCHES_PROC) += patches.o obj-$(CONFIG_STOP_MACHINE) += stop_machine.o obj-$(CONFIG_AUDIT) += audit.o obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
@@ -52,3 +54,17 @@ targets += config_data.h $(obj)/config_data.h: $(obj)/config_data.gz FORCE $(call if_changed,ikconfiggz) + +$(obj)/patches.o: $(obj)/patches_data.h + +# patches_data.h contains the same information as ikpatches.h but gzipped. +# Info from patches_data can be extracted from /proc/patches* +targets += patches_data.gz +$(obj)/patches_data.gz: .patches FORCE + $(call if_changed,gzip) + +quiet_cmd_ikpatchesgz = IKPTC $@ + cmd_ikpatchesgz = (echo "static const char kernel_patches_data[] = MAGIC_START"; cat $< | scripts/bin2c; echo "MAGIC_END;") > $@ +targets += patches_data.h +$(obj)/patches_data.h: $(obj)/patches_data.gz FORCE + $(call if_changed,ikpatchesgz)
kernel/patches.c +115 -0
115 lines not on this page · raw message
Quoted 13 lines · Adrian Bunk
Quoted 11 lines · Christian Hesse
Hi everybody,
every time I apply a patch to my kernel tree I (or my scripts) make an
echo $PATCHNAME $PATCHVERSION >> .patches
This patch makes the file accessible via
/proc/patches.gz. I think this can be handy if you want to know what patches you (or your distributor) applied to your running kernel...
...
Let me know what you think.
Quoted 5 lines
To be honest, I'm not a fan of it.
If e.g. looking at a Debian kernel source that has 289 different patches with names like tty-locking-fixes7 applied, you'll see that this often won't give you much valuable information.
You can search Debian lists, archives, ... for "tty-locking-fixes7". After that you probably know what the fix is good for.
On the other hand if there is a security fix in a Debian list you can check if your kernel is patched by running "zcat /proc/patches.gz | grep security-fix-foo-bar".
Quoted 2 lines
You'd need an uniform naming convention for patches across distributions, and I don't think such things are worth the effort.
If a distribution has a naming convention for itself this patch can already be useful I think. Even without it can be.
Signature · 1 line
Christian
Quoted 14 lines · Christian Hesse
Quoted 13 lines · Adrian Bunk
Quoted 11 lines · Christian Hesse
Hi everybody,
every time I apply a patch to my kernel tree I (or my scripts) make an
echo $PATCHNAME $PATCHVERSION >> .patches
This patch makes the file accessible via
/proc/patches.gz. I think this can be handy if you want to know what patches you (or your distributor) applied to your running kernel...
...
Let me know what you think.
Quoted 8 lines
Quoted 5 lines
To be honest, I'm not a fan of it.
If e.g. looking at a Debian kernel source that has 289 different patches with names like tty-locking-fixes7 applied, you'll see that this often won't give you much valuable information.
You can search Debian lists, archives, ... for "tty-locking-fixes7". After that you probably know what the fix is good for.
The _only_ Google hit for "tty-locking-fixes7" isn't very helpful.
I could simply download the source package for the kernel...
Quoted 3 lines
On the other hand if there is a security fix in a Debian list you can check if your kernel is patched by running "zcat
/proc/patches.gz| grep security-fix-foo-bar".
"zless /usr/share/doc/<pkgname>/Debian.src.changelog.gz" already gives you the same information plus information about the contents of the patches including CAN references and bug numbers.
Quoted 5 lines
Quoted 2 lines
You'd need an uniform naming convention for patches across distributions, and I don't think such things are worth the effort.
If a distribution has a naming convention for itself this patch can already be useful I think. Even without it can be.
If you are building your own kernel, you have to manually check that you don't forget to add every patch you apply to .patches .
In a distribution, the information is already present at better places.
Quoted 1 line
Christian
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed