Perhaps times have changed enough that I can revive this idea from a
few years ago:
http://groups.google.com/groups?q=patchname+oxymoron&hl=en&lr=&ie=UTF-8&selm=fa.jif8l5v.1b049jd%40ifi.uio.no&rnum=1
<quote year=1999>
This four-line patch provides a means for listing what patches have
been built into a kernel. This will help track non-standard kernel
versions, such as those released by Redhat, or Alan's ac series, etc.
more easily.
With this patch in place, each new patch can include a file of the
form "patchname.[identifier]" in the top level source directory and
[identifier] will then be added to the kernel version string. For
instance, Alan's ac patches could include a file named patchdesc.ac2
(containing a change log, perhaps), and the resulting kernel would be
identified as 2.2.0-pre6+ac2, both at boot and by uname.
This may prove especially useful for tracking problems with kernels
built by distribution packagers and problems reported by automated
tools.
</quote>
The patch now appends patches as -name rather than +name to avoid
issues that might exist with packaging tools and scripts.
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/Makefile patched/Makefile
--- orig/Makefile 2003-07-29 13:31:50.000000000 -0500
+++ patched/Makefile 2003-07-29 15:25:36.000000000 -0500
@@ -25,7 +25,10 @@
# descending is started. They are now explicitly listed as the
# prepare rule.
-KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
+PATCHES=$(shell find -maxdepth 1 -name 'patchdesc.*[^~]' -printf '+%f' | \
+ sed -e 's/+patchdesc\./-/g')
+KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(PATCHES)
+
# SUBARCH tells the usermode build what the underlying arch is. That is set
# first, and if a usermode build is happening, the "ARCH=um" on the command
@@ -504,7 +507,7 @@
)
endef
-include/linux/version.h: Makefile
+include/linux/version.h: Makefile patchdesc.*
$(call filechk,version.h)
# ---------------------------------------------------------------------------
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Oliver Xymoron said:
> Perhaps times have changed enough that I can revive this idea from a
> few years ago:
>
> http://groups.google.com/groups?q=patchname+oxymoron&hl=en&lr=&ie=UTF-8&selm=fa.jif8l5v.1b049jd%40ifi.uio.no&rnum=1
>
> <quote year=1999>
> This four-line patch provides a means for listing what patches have
> been built into a kernel. This will help track non-standard kernel
> versions, such as those released by Redhat, or Alan's ac series, etc.
> more easily.
>
> With this patch in place, each new patch can include a file of the
> form "patchname.[identifier]" in the top level source directory and
> [identifier] will then be added to the kernel version string. For
> instance, Alan's ac patches could include a file named patchdesc.ac2
> (containing a change log, perhaps), and the resulting kernel would be
> identified as 2.2.0-pre6+ac2, both at boot and by uname.
>
> This may prove especially useful for tracking problems with kernels
> built by distribution packagers and problems reported by automated
> tools.
> </quote>
>
> The patch now appends patches as -name rather than +name to avoid
> issues that might exist with packaging tools and scripts.
<snip>
One problem I see right off the bat with this is that your kernel image
name (and label) in LILO can only be so long, and if you apply too many
patches (acpi+xfs+preempt+low etc.) it would become too long. This may be
an extreme case, but it can happen (I usually apply apci, preempt, low,
sched, etc., though the ck patch does most of this for me now).
-sandalle
--
PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o?
K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++)
tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+
------END GEEK CODE BLOCK------
Eric Sandall | Source Mage GNU/Linux Developer
[email protected] | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
On Tue, Jul 29, 2003 at 03:15:02PM -0700, Eric Sandall wrote:
>
> Oliver Xymoron said:
> > Perhaps times have changed enough that I can revive this idea from a
> > few years ago:
> >
> > http://groups.google.com/groups?q=patchname+oxymoron&hl=en&lr=&ie=UTF-8&selm=fa.jif8l5v.1b049jd%40ifi.uio.no&rnum=1
> >
> > <quote year=1999>
> > This four-line patch provides a means for listing what patches have
> > been built into a kernel. This will help track non-standard kernel
> > versions, such as those released by Redhat, or Alan's ac series, etc.
> > more easily.
> >
> > With this patch in place, each new patch can include a file of the
> > form "patchname.[identifier]" in the top level source directory and
> > [identifier] will then be added to the kernel version string. For
> > instance, Alan's ac patches could include a file named patchdesc.ac2
> > (containing a change log, perhaps), and the resulting kernel would be
> > identified as 2.2.0-pre6+ac2, both at boot and by uname.
> >
> > This may prove especially useful for tracking problems with kernels
> > built by distribution packagers and problems reported by automated
> > tools.
> > </quote>
> >
> > The patch now appends patches as -name rather than +name to avoid
> > issues that might exist with packaging tools and scripts.
> <snip>
>
> One problem I see right off the bat with this is that your kernel image
> name (and label) in LILO can only be so long, and if you apply too many
> patches (acpi+xfs+preempt+low etc.) it would become too long. This may be
> an extreme case, but it can happen (I usually apply apci, preempt, low,
> sched, etc., though the ck patch does most of this for me now).
There's already code in the makefile that warns when it grows over 64
characters.
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
On Tue, Jul 29, 2003 at 03:44:19PM -0500, Oliver Xymoron wrote:
> Perhaps times have changed enough that I can revive this idea from a
> few years ago:
>
> http://groups.google.com/groups?q=patchname+oxymoron&hl=en&lr=&ie=UTF-8&selm=fa.jif8l5v.1b049jd%40ifi.uio.no&rnum=1
>
> <quote year=1999>
> This four-line patch provides a means for listing what patches have
> been built into a kernel. This will help track non-standard kernel
> versions, such as those released by Redhat, or Alan's ac series, etc.
> more easily.
>
> With this patch in place, each new patch can include a file of the
> form "patchname.[identifier]" in the top level source directory and
> [identifier] will then be added to the kernel version string. For
> instance, Alan's ac patches could include a file named patchdesc.ac2
> (containing a change log, perhaps), and the resulting kernel would be
> identified as 2.2.0-pre6+ac2, both at boot and by uname.
>
> This may prove especially useful for tracking problems with kernels
> built by distribution packagers and problems reported by automated
> tools.
> </quote>
>
> The patch now appends patches as -name rather than +name to avoid
> issues that might exist with packaging tools and scripts.
Has anything happened with this patch?
I for one would love it to be merged.
On Tue, 5 Aug 2003 12:17:18 -0700 Mike Fedyk <[email protected]> wrote:
| On Tue, Jul 29, 2003 at 03:44:19PM -0500, Oliver Xymoron wrote:
| > Perhaps times have changed enough that I can revive this idea from a
| > few years ago:
| >
| > http://groups.google.com/groups?q=patchname+oxymoron&hl=en&lr=&ie=UTF-8&selm=fa.jif8l5v.1b049jd%40ifi.uio.no&rnum=1
| >
| > <quote year=1999>
| > This four-line patch provides a means for listing what patches have
| > been built into a kernel. This will help track non-standard kernel
| > versions, such as those released by Redhat, or Alan's ac series, etc.
| > more easily.
| >
| > With this patch in place, each new patch can include a file of the
| > form "patchname.[identifier]" in the top level source directory and
| > [identifier] will then be added to the kernel version string. For
| > instance, Alan's ac patches could include a file named patchdesc.ac2
| > (containing a change log, perhaps), and the resulting kernel would be
| > identified as 2.2.0-pre6+ac2, both at boot and by uname.
| >
| > This may prove especially useful for tracking problems with kernels
| > built by distribution packagers and problems reported by automated
| > tools.
| > </quote>
| >
| > The patch now appends patches as -name rather than +name to avoid
| > issues that might exist with packaging tools and scripts.
|
| Has anything happened with this patch?
|
| I for one would love it to be merged.
I saved it, as you did too apparently.
Looks nice to me as well.
--
~Randy
On Tue, Aug 05, 2003 at 12:33:49PM -0700, Randy.Dunlap wrote:
> On Tue, 5 Aug 2003 12:17:18 -0700 Mike Fedyk <[email protected]> wrote:
>
> | On Tue, Jul 29, 2003 at 03:44:19PM -0500, Oliver Xymoron wrote:
> | > Perhaps times have changed enough that I can revive this idea from a
> | > few years ago:
> | >
> | > http://groups.google.com/groups?q=patchname+oxymoron&hl=en&lr=&ie=UTF-8&selm=fa.jif8l5v.1b049jd%40ifi.uio.no&rnum=1
> | >
> | > <quote year=1999>
> | > This four-line patch provides a means for listing what patches have
> | > been built into a kernel. This will help track non-standard kernel
> | > versions, such as those released by Redhat, or Alan's ac series, etc.
> | > more easily.
> | >
> | > With this patch in place, each new patch can include a file of the
> | > form "patchname.[identifier]" in the top level source directory and
> | > [identifier] will then be added to the kernel version string. For
> | > instance, Alan's ac patches could include a file named patchdesc.ac2
> | > (containing a change log, perhaps), and the resulting kernel would be
> | > identified as 2.2.0-pre6+ac2, both at boot and by uname.
> | >
> | > This may prove especially useful for tracking problems with kernels
> | > built by distribution packagers and problems reported by automated
> | > tools.
> | > </quote>
> | >
> | > The patch now appends patches as -name rather than +name to avoid
> | > issues that might exist with packaging tools and scripts.
> |
> | Has anything happened with this patch?
> |
> | I for one would love it to be merged.
>
> I saved it, as you did too apparently.
> Looks nice to me as well.
The powers that be may have noticed that the posted version was broken
in the case of no description files. This version gets the dependency
stuff right. The above description also doesn't mention that this
solves the patch conflict problem that results from touching
EXTRAVERSION directly.
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/Makefile patched/Makefile
--- orig/Makefile 2003-07-31 10:39:39.000000000 -0500
+++ patched/Makefile 2003-07-31 11:39:02.000000000 -0500
@@ -25,7 +25,10 @@
# descending is started. They are now explicitly listed as the
# prepare rule.
-KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
+PATCHES=$(shell find -maxdepth 1 -name 'patchdesc.*[^~]' -printf '+%f' | \
+ sed -e 's/+patchdesc\./-/g')
+KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(PATCHES)
+
# SUBARCH tells the usermode build what the underlying arch is. That is set
# first, and if a usermode build is happening, the "ARCH=um" on the command
@@ -504,7 +507,11 @@
)
endef
-include/linux/version.h: Makefile
+# We either have to keep track of the previous patchdesc.* files or check
+# version at every build
+.PHONY: always-check-version
+
+include/linux/version.h: Makefile always-check-version
$(call filechk,version.h)
# ---------------------------------------------------------------------------
--
Matt Mackall : http://www.selenic.com : of or relating to the moon