RFC -- /proc/patches to track development

RFC -- /proc/patches to track development

[Marty Leisner]

I always want to know WHAT I'm running (or people I'm working with
are running) rather than  "guessing" ("do you have the most current 
patch" "I think so")

I've been a proponent of capturing .config information SOMEPLACE where
you can look at it at runtime...(it took a while but its there now).


In /proc/patches there would be a series of comments (perhaps including
file, date and time) of various patches you want to monitor.  

It would be enabled by something like

in file foo.c:
PATCH_COMMENT("this enables the foo feature");


In membar.c:
PATCH_COMMENT("go to the bar on saturday");
...
PATCH_COMMENT("watch how much you drink");


and in /proc/patches:

foo.c: compiled <date> <time>:this enables the foo feature
membar.c: compiled <date> <time>:go to the bar on saturday
member.c: compiled <date> <time>:watch how much you drink

There would be a Kconfig flag whether or not to enable this (i.e.
production kernels would not need it,
hacked kernels would, it could always be there if you're willing to
increase the footprint).

Instead of looking for aberrant behavior to identify patches, you could easily
see things with cat.

Seems very easy and has high ROI if you need to track patched kernels locally.


marty

Re: RFC -- /proc/patches to track development

[Jan Engelhardt]

>From: Marty Leisner <leisner@rochester.rr.com>
>Subject: RFC  -- /proc/patches to track development 
                  ^^^^^

Wrong place. Really. (And I do not think /sys is a better one either. 
But let others speak up.)

>I always want to know WHAT I'm running (or people I'm working with

`uname -a`?

>are running) rather than  "guessing" ("do you have the most current 
>patch" "I think so")
>
>I've been a proponent of capturing .config information SOMEPLACE where
>you can look at it at runtime...(it took a while but its there now).

/proc/config,gz?

>In /proc/patches there would be a series of comments (perhaps including
>file, date and time) of various patches you want to monitor.  

Wastes nonswappable memory.

>It would be enabled by something like
>
>in file foo.c:
>PATCH_COMMENT("this enables the foo feature");
>
>
>In membar.c:
>PATCH_COMMENT("go to the bar on saturday");
>...
>PATCH_COMMENT("watch how much you drink");
>
>
>and in /proc/patches:
>
>foo.c: compiled <date> <time>:this enables the foo feature
>membar.c: compiled <date> <time>:go to the bar on saturday
>member.c: compiled <date> <time>:watch how much you drink
>
>There would be a Kconfig flag whether or not to enable this (i.e.
>production kernels would not need it,
>hacked kernels would, it could always be there if you're willing to
>increase the footprint).

Reasonable. However, I would prefer that PATCH_COMMENT() evaluates to a 
string that is included in the module only (think MODULE_DESCRIPTION) 
and is not loaded during modprobe. Instead, modinfo your 
/lib/modules/`uname -r` tree and grep for your PATCH_COMMENT lines. Hey, 
that's even in userspace - no memory wasted.

>Instead of looking for aberrant behavior to identify patches, you could easily
>see things with cat.

Can you define patch? IMO, if you run a normal, mm, or git kernel, you 
usually find -mm or -git in the `uname -r` output. Of course there is 
also some development going on between -gitA and -gitB, but most people 
seem to keep together what they have patched.

>Seems very easy and has high ROI if you need to track patched kernels locally.

Patched by whom? (Tier-1 kernel developers (mainline, mm and those who 
run a tree on git.kernel.org), or Tier-2+ (Distro vendors))



	-`J'
-- 

Re: RFC -- /proc/patches to track development

[Erik Mouw]

On Tue, Nov 14, 2006 at 08:17:03PM -0500, Marty Leisner wrote:
> I always want to know WHAT I'm running (or people I'm working with
> are running) rather than  "guessing" ("do you have the most current 
> patch" "I think so")
> 
> I've been a proponent of capturing .config information SOMEPLACE where
> you can look at it at runtime...(it took a while but its there now).
> 
> 
> In /proc/patches there would be a series of comments (perhaps including
> file, date and time) of various patches you want to monitor.  

[...]

> Seems very easy and has high ROI if you need to track patched kernels
> locally.

Even easier and doesn't need any kernel features or special comments:
use git to track your patches, enable CONFIG_LOCALVERSION_AUTO and
uname will tell you exactly what kernel you're running:

  erik@kostunrix:~ > uname -r
  2.6.18-gf6057327

To see what's different, just use git:

  git log --no-merges v2.6.18..f6057327 | git-shortlog

  Erik Mouw (1):
        2.6.18-rc6 config for kostunrix


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: RFC -- /proc/patches to track development

[Hesse, Christian]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On Wednesday 15 November 2006 02:17, Marty Leisner wrote:
> I always want to know WHAT I'm running (or people I'm working with
> are running) rather than  "guessing" ("do you have the most current
> patch" "I think so")
>
> I've been a proponent of capturing .config information SOMEPLACE where
> you can look at it at runtime...(it took a while but its there now).
>
>
> In /proc/patches there would be a series of comments (perhaps including
> file, date and time) of various patches you want to monitor.

I prepared such a patch [0] some time ago. It makes the file .patches in 
kernel source tree available via /proc/patches.gz. Read the discussion on 
lkml [1] to get more information. It still appies to actual kernels.

[0] http://www.earthworm.de/download/linux/patches.patch
[1] 
http://groups.google.com/group/linux.kernel/browse_thread/thread/68497374c5870617/6cfc8eed92e9b7ff
-- 
Regards,
Christian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]