All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Christian Hesse <mail@earthworm.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Kernel .patches support
Date: Sat, 25 Jun 2005 00:31:15 +0200	[thread overview]
Message-ID: <20050624223115.GL6656@stusta.de> (raw)
In-Reply-To: <200506242303.17813.mail@earthworm.de>

On Fri, Jun 24, 2005 at 11:03:17PM +0200, Christian Hesse wrote:
> 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

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


      reply	other threads:[~2005-06-24 22:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-23 21:58 [PATCH] Kernel .patches support Christian Hesse
2005-06-23 22:38 ` Karim Yaghmour
2005-06-24  6:02 ` Ian Campbell
2005-06-24  7:36 ` Adrian Bunk
2005-06-24  8:57   ` Coywolf Qi Hunt
2005-06-24 20:48     ` Christian Hesse
2005-06-24 21:03   ` Christian Hesse
2005-06-24 22:31     ` Adrian Bunk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050624223115.GL6656@stusta.de \
    --to=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@earthworm.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.