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,
--
Christian
I haven't looked at the implementation, but I love the functionality.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I haven't looked, but would it be possible to share this code instead of
copying it ?
--
Ian Campbell
Waking a person unnecessarily should not be considered a capital crime.
For a first offense, that is.
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.
> Regards,
> Christian
> --- linux-2.6.12+/include/linux/patches.h 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.12+-patches/include/linux/patches.h 2005-06-23 23:10:15.278685000 +0200
> @@ -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
--
"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
Stupid me. It was too late last night. :)
You're right, I removed the file and included linux/config.h in
kernel/patches.c.
--
Christian
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".
> 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.
--
Christian
The _only_ Google hit for "tty-locking-fixes7" isn't very helpful.
I could simply download the source package for the kernel...
> 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.
> > 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.
> Christian
> 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...
there is no clean namespace for patch filenames or a consistent
registry
for it to be useful you would need to embed the patches themselves
into the kernel which is a horrendous thought