Proposal and Patch: Listing of Patches while Booting

• Patch Index 2.0 Unofficial Patches
  
• Previous Patch: flexible refill_freelist 2.0.30 patch
  
• Next Patch: refill_freelist patch
  

Yesterday I toyed around a little with the 2.0.30 kernel and its various pre-2.0.30, buffer cache and other patches which are available from www.linuxhq.com. Of course I got lost in the middle of patching and ended up with a mess where I was not able to track any longer which of my kernels booted up with what patch and release because they all called itself "2.0.30". Even the usage of "2030-pre-2-cache-menu-n-stuff" as filenames was not _that_ satisfying. So I mused about some kind of scheme where each patch could register itself at compile time and report when booting.

In fact I came up with the following patch. The idea is:

You get a directory called init/patches where each (official, unofficial or RedHat :-) ) patch can put a file with one line of description. I\264ll show you for the prominent pre-2.0.30-2. You add this to the pre-patch file:

--- cut ---
diff -u --recursive --new-file linux-2.0.30/init/patches/pre2.0.30 linux-2.0.30p/init/patches/pre2.0.30-2
--- linux-2.0.30/init/patches/pre2.0.30 Thu Jan  1 01:00:00 1970
+++ linux-2.0.30p/init/patches/pre2.0.30      Mon Jul  7 09:06:07 1997
@@ -0,0 +1 @@
+Linux 2.0.31 Pre-Patch 2 (David S. Miller)
--- cut ---

So you get, when applying the pre-patch, a file called "pre2.0.30" in the init/patches directory, which contains one line:

Linux 2.0.31 Pre-Patch 2 (David S. Miller)

Same goes for all other patches that you use and/or apply. You have to change the name of the created file (of course) and, after applying serveral patches, you end up with a description file for each patch.

This is even nice if you don't apply the kernel patch below (against a clean 2.0.30 tree it works, I see no reason why it shouldn't work against other 2.0.x trees (I don't do 2.1.x yet) but I didn't actually tried out.

If you apply the patch you get the following while booting:

Jul  7 17:41:37 forge kernel: Linux version 2.0.30 (henning@forge) (gcc version2.7.2.1) #3 Mon Jul 7 17:28:26 MET DST 1997
Jul  7 17:41:37 forge kernel: *** Installed patches:
Jul  7 17:41:37 forge kernel: Linux Config IP Route Patch
Jul  7 17:41:37 forge kernel: Linux Ext2 Filesystem Immuteable Flag Fix
Jul  7 17:41:37 forge kernel: Clear inode Race fix (Bill Hawes, 4.7.97)
Jul  7 17:41:37 forge kernel: Linux Menu Config Patch (Official Release)
Jul  7 17:41:37 forge kernel: Linux Unofficial Patch Printout (2.0.30)
Jul  7 17:41:37 forge kernel: Linux Page Cache Swapper (Dr. Werner Fink)
Jul  7 17:41:37 forge kernel: Linux 2.0.31 Pre-Patch 2 (David S. Miller)
Jul  7 17:41:37 forge kernel: *** End of Patches

As you may have guessed, everything between "*** Installed patches:" and "*** End of patches" are the contents of the files in init/patches. So you can see while booting what you currently did to your kernel and see which patches are installed.

I thought of this as useful (well more useful than naming a kernel :-) ), maybe someone else will think of this too. I doubt that this should be integrated into mainline 2.0.x kernels at this stage but it would be nice to see an unified patch documentation scheme in 2.1.x and beyond. Yes, I know that\264s what the release number was intended for but face it: There are and will always be "unofficial" patches or patches that are not part of the official kernel tree for some or other reason (look what RedHat did to the 2.0.x kernes) and I would think of it as nice if there is some way to actually document these changes and patches at some central place in the kernel.