[PATCH] Kernel .patches support
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...
Most of the code is copy & past from CONFIG_IKCONFIG[_PROC].
Let me know what you think.
Regards,
--
Christian
Karim Yaghmour
Christian Hesse wrote:
> 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
--
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/
Ian Campbell
> 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 ?
--
Ian Campbell
Waking a person unnecessarily should not be considered a capital crime.
For a first offense, that is.
Adrian Bunk
> 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.
> 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
Coywolf Qi Hunt
> On Thu, Jun 23, 2005 at 11:58:27PM +0200, Christian Hesse wrote:
> > --- 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?
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
Christian Hesse
> On 6/24/05, Adrian Bunk <bu...@stusta.de> wrote:
> > On Thu, Jun 23, 2005 at 11:58:27PM +0200, Christian Hesse wrote:
> > > --- 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?
>
> 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.
--
Christian
Christian Hesse
> On Thu, Jun 23, 2005 at 11:58:27PM +0200, Christian Hesse wrote:
> > 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 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
Adrian Bunk
> On Friday 24 June 2005 09:36, Adrian Bunk wrote:
> > On Thu, Jun 23, 2005 at 11:58:27PM +0200, Christian Hesse wrote:
> > > 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 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...
> 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
Chris Wedgwood
> 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