Re: [PATCH] [RFC] adding support for .patches and /proc/patches.gz

From: Cef (LKML)
Date: Wed May 12 2004 - 03:32:11 EST

On Wed, 12 May 2004 14:59, Jon Oberheide wrote:
> Any patches applied against the current vanilla kernel would
> be listed in .patches. This would include vendor, third-party, and even
> pre/bk/mm patches.
> Keep in mind, .patches would not contain the entire patch, as that would
> be WAY to large, but just a short entry such as the name, date last
> modified, and date applied of the patch file.

A URI would always be nice. That way the originator of the patch can be
contacted and/or the patch can be fetched easily, all without the original
kernel source.

In fact, it seems to me that BK (or in fact any patch management system) could
prove useful here. Not only could it list merged changesets in .patches, it
could also provide a URI for the author or the repo/patch. And as the kernel
tree moves and the patches get pushed into releases, the .patches file gets
cleared of everything that exists in the base tree. Really, something like a
translated output of the BK changelog for a tree would probably do the job.
Much like, but more compact information wise. Providing a
tool at least would get it out in the open and used.

Of course, then you have to define what the base is, and really this should be
the first thing in .patches - You need to state what the baseline is you're
comparing against. It'd be good if it wasn't in a separate place. That
increases it's versatility greatly.

For something like this to happen with BK (ie: as a BitMover provided app),
you may want to talk to Larry McVoy - it's his baby after all. Of course, you
could just hack on yourself.

Stuart Young (aka Cef)
cef-lkml@xxxxxxxxxxxxxxx is for LKML and related email only
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at