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

[Jon Oberheide]

Greetings,

This feature has been brought up several times before, as can be seen
here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.3/0798.html
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0598.html
http://www.uwsg.iu.edu/hypermail/linux/kernel/9803.0/0223.html

For those unfamiliar, a file linux/.patches would be adding to the
source tree.  When applying patches to the source tree, descriptive
information would be written to .patches.  After compilation and running
of this kernel, the .patches information would be accessible through
/proc/patches.gz; similar to the /proc/config.gz feature.

When a user requests help troubleshooting, they can send a developer the
output of `zcat /proc/patches.gz` along with their /proc/config.gz,
traces, dmesg, etc.  A list of applied patches to the user's source tree
can make it much easier and quicker to track down a bug.  In addition,
users of stock distribution kernels will be able to identify all the
patches applied by "Your Favorite Distro".

Getting .patches adopted into common use is the main problem.  Here are
several solutions towards making effective use of .patches...in order
from terrible to ideal:


Solution 1:
Free-for-all .patches file.  Vendors and developers could write whatever
data they see fit to the file.
Pros: NULL
Cons: TOO much flexibility; no structure; confusion; flash floods; would
render .patches practically useless

Solution 2:
Use a format similar to the MAINTAINERS to keep information about
applied patches.
Pros: uniform structure; descriptive data
Cons: additional code would be necessary to modify the .patches file
which is not very desirable when passing around small diffs.

Solution 3:
Incorporate a command line flag (or possibly a wrapper) in patch (such
as -k) to indicate that the user will be performing a kernel patch and
therefore patch should write information (such as the patch filename,
date, etc) to .patches in a uniform format.  Patch information could be
inserted into .patches when a patch is applied and removed when it is
reserved (-R).
Pros: Automatic insertion/removal into .patches via normal diff's;
requires no extra code besides the -k flag
Cons: All vendors would have to modify their utilities and remember to
pass this flag to patch; users/developers manually patching would have
to remember it as well.

Solution 4:
Incorporate insertion and removal globally into patch without the need
for a flag (perhaps have a flag to NOT use it if desired).  Patch
information could be inserted into .patches when a patch is applied and
removed when it is reserved (-R).
Pros: Automatic insertion/removal into .patches via normal diff's; no
vendor, developer, user intervention required to implement; the .patches
file could be easily used by other software as it would be default in
patch;
Cons: politics: an arguably radical change to patch


I'm CC'ing this to the GNU patch maintainers.  Hopefully they will have
some input.  Attached is four patch files which apply to
2.6.6-rc3-bk11.  It would likely be best for these to sit in mm until
one of the above solutions is reached:

dotpatches-Kconfig: Kconfig update and .patches creation
dotpatches-defconfigs: set defconfigs identical to /proc/config feature
dotpatches-kernel: modifications in linux/kernel
dotpatches-scripts: modifications in linux/scripts


Regards,
Jon Oberheide
address@hidden

dotpatches-Kconfig.patch
Description: Text Data

dotpatches-defconfigs.patch
Description: Text Data

dotpatches-kernel.patch
Description: Text Data

dotpatches-scripts.patch
Description: Text Data

signature.asc
Description: This is a digitally signed message part