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
>From: Marty Leisner <[email protected]>
>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'
--
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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
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