Hi all,
Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.
I've tracked it down to include/linux/compile.h always being updated,
and this is because .version is updated. I couldn't find what is
causing .version to be updated each time though. Can anybody help
there? Was this change made on purpose or is this a bug which we should
fix?
Thanks,
--
Jean Delvare
On Tuesday 09 January 2007 04:20, Jean Delvare wrote:
>Hi all,
>
>Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
>an incremented version number, whether there has actually been any
>change done to the code or configuration or not. This increases the
>build time quite a bit.
>
>I've tracked it down to include/linux/compile.h always being updated,
>and this is because .version is updated. I couldn't find what is
>causing .version to be updated each time though. Can anybody help
>there? Was this change made on purpose or is this a bug which we should
>fix?
>
>Thanks,
I've not seen that here, Jean. But then my 'makeit' script doesn't use a
plain 'make' anyplace, always 'make bzimage' or 'make modules' & 'make
modules install', etc.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
Jean Delvare wrote:
> Hi all,
>
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
>
> I've tracked it down to include/linux/compile.h always being updated,
> and this is because .version is updated. I couldn't find what is
> causing .version to be updated each time though. Can anybody help
> there? Was this change made on purpose or is this a bug which we should
> fix?
I have been bitten by this as well; I have tracked it down to defining
CONFIG_KALLSYMS:
define rule_vmlinux__
:
$(if $(CONFIG_KALLSYMS),,+$(call cmd,vmlinux_version))
quiet_cmd_vmlinux_version = GEN .version
cmd_vmlinux_version = set -e; \
if [ ! -r .version ]; then \
rm -f .version; \
echo 1 >.version; \
else \
mv .version .old_version; \
expr 0$$(cat .old_version) + 1 >.version; \
fi; \
$(MAKE) $(build)=init
Pondering about it, this may be a feature not a bug. Let's assume you have
changed a single function name anywhere - you need to rebuild kallsyms
(ergo vmlinux) for that.
OTOH I do not know if kallsyms include also symbols from modules; if no,
this is indeed a bug.
-andrey
Hi Andrey,
On Tue, 09 Jan 2007 20:05:49 +0300, Andrey Borzenkov wrote:
> Jean Delvare wrote:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or configuration or not. This increases the
> > build time quite a bit.
> >
> > I've tracked it down to include/linux/compile.h always being updated,
> > and this is because .version is updated. I couldn't find what is
> > causing .version to be updated each time though. Can anybody help
> > there? Was this change made on purpose or is this a bug which we should
> > fix?
>
> I have been bitten by this as well; I have tracked it down to defining
> CONFIG_KALLSYMS:
>
> define rule_vmlinux__
> :
> $(if $(CONFIG_KALLSYMS),,+$(call cmd,vmlinux_version))
>
> quiet_cmd_vmlinux_version = GEN .version
> cmd_vmlinux_version = set -e; \
> if [ ! -r .version ]; then \
> rm -f .version; \
> echo 1 >.version; \
> else \
> mv .version .old_version; \
> expr 0$$(cat .old_version) + 1 >.version; \
> fi; \
> $(MAKE) $(build)=init
>
>
> Pondering about it, this may be a feature not a bug. Let's assume you have
> changed a single function name anywhere - you need to rebuild kallsyms
> (ergo vmlinux) for that.
>
> OTOH I do not know if kallsyms include also symbols from modules; if no,
> this is indeed a bug.
I don't think this is the problem here. The kernel keeps being
recompiled even when _nothing_ has changed. This wasn't the case up to
2.6.19, while the code above has been there untouched since 2.6.14.
I tried a git bisect to find out what commit was reponsible for it, and
the winner is...
8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
commit 8993780a6e44fb4e7ed34e33458506a775356c6e
Author: Linus Torvalds <[email protected]>
Date: Mon Dec 11 09:28:46 2006 -0800
Make SLES9 "get_kernel_version" work on the kernel binary again
As reported by Andy Whitcroft, at least the SLES9 initrd build process
depends on getting the kernel version from the kernel binary. It does
that by simply trawling the binary and looking for the signature of the
"linux_banner" string (the string "Linux version " to be exact. Which
is really broken in itself, but whatever..)
That got broken when the string was changed to allow /proc/version to
change the UTS release information dynamically, and "get_kernel_version"
thus returned "%s" (see commit a2ee8649ba6d71416712e798276bf7c40b64e6e5:
"[PATCH] Fix linux banner utsname information").
This just restores "linux_banner" as a static string, which should fix
the version finding. And /proc/version simply uses a different string.
To avoid wasting even that miniscule amount of memory, the early boot
string should really be marked __initdata, but that just causes the same
bug in SLES9 to re-appear, since it will then find other occurrences of
"Linux version " first.
Cc: Andy Whitcroft <[email protected]>
Acked-by: Herbert Poetzl <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Steve Fox <[email protected]>
Acked-by: Olaf Hering <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
:040000 040000 1dfdf42f80828c413baba65a1ce8b460c9712ded cdb83fd26232860493d9e993af467e1dff77da83 M fs
:040000 040000 94ad8c94d5ce333ad8febdc508a37de768736a98 12bc13def90d15921d41d2b285854b3e157a970f M include
:040000 040000 991e9baa5a61b998a0e4833e142d5c4f72d61729 5673719c3f6b47b329cfc9554c112077634a9b19 M init
Reverting this from 2.6.20-rc1 made the build behave again, however I
found that reverting it from 2.6.20-rc2 did _not_ fix the problem. I
also had to revert the following patch to make things work as before
again:
commit ef129412b4cbd6686d0749612cb9b76e207271f4
Author: Andrew Morton <[email protected]>
Date: Fri Dec 22 01:12:01 2006 -0800
[PATCH] build compile.h earlier
compile.h is created super-late in the build. But proc_misc.c want to include
it, and it's generally not sane to have a header file in include/linux be
created at the end of the build: it's either not present or, worse, wrong for
most of the build.
So the patch arranges for compile.h to be built at the start of the build
process. It also consolidates the compile.h rules with those for version.h
and utsname.h, so they all get built together.
I hope. My chances of having got this right are about 2%.
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
I can only second Andrew's commit's last sentence ;)
So, Linus, Andrew, can you please take a look and revert or fix what
needs to be? This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
Thanks,
--
Jean Delvare
On Tue, 9 Jan 2007 21:44:21 +0100
Jean Delvare <[email protected]> wrote:
> So, Linus, Andrew, can you please take a look and revert or fix what
> needs to be?
Am afraid to touch it. Sam should be back on deck soon and will hopefully
have time to fix this stuff up.
> This new behavior of the kernel build system is likely to
> make developers angry pretty quickly.
That might motivate them to fix it ;)
Jean Delvare <[email protected]> ha scritto:
> Hi all,
Hi Jean,
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
>
> I've tracked it down to include/linux/compile.h always being updated,
> and this is because .version is updated. I couldn't find what is
> causing .version to be updated each time though. Can anybody help
> there? Was this change made on purpose or is this a bug which we should
> fix?
kronos:~/src/linux-2.6.git$ cat ../linux-build-git/include/linux/compile.h
/* This file is auto generated, version 14 */
/* SMP PREEMPT */
#define UTS_MACHINE "i386"
#define UTS_VERSION "#14 SMP PREEMPT Tue Jan 9 22:45:18 CET 2007"
#define LINUX_COMPILE_TIME "22:45:18"
#define LINUX_COMPILE_BY "kronos"
#define LINUX_COMPILE_HOST "dreamland.darkstar.lan"
#define LINUX_COMPILE_DOMAIN "darkstar.lan"
#define LINUX_COMPILER "gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)"
LINUX_COMPILE_TIME and UTS_VERSION differs at each rebuild. UTS_VERSION
is responsible of rebuilding fs/proc/proc_misc.o; init/main.o uses just
about everything, init/version.o requires UTS_VERSION.
I don't think it's a regression from earlier kernels though, is it?
kronos:~/src/linux-2.6.git$ make -j3 V=2 O=../linux-build-git/
GEN /home/kronos/src/linux-build-git/Makefile
CHK include/linux/version.h
CHK include/linux/compile.h
CHK include/linux/utsrelease.h
Using /home/kronos/src/linux-2.6.git as source for kernel
UPD include/linux/compile.h
CC init/main.o - due to: include/linux/compile.h
CC init/version.o - due to: include/linux/compile.h
LD init/built-in.o - due to: init/main.o init/version.o
CC fs/proc/proc_misc.o - due to: include/linux/compile.h
LD fs/proc/proc.o - due to: fs/proc/proc_misc.o
LD fs/proc/built-in.o - due to: fs/proc/proc.o
LD fs/built-in.o - due to: fs/proc/built-in.o
GEN .version - due to: init/built-in.o fs/built-in.o
LD .tmp_vmlinux1 - due to: init/built-in.o fs/built-in.o
KSYM .tmp_kallsyms1.S - due to: .tmp_vmlinux1
AS .tmp_kallsyms1.o - due to: .tmp_kallsyms1.S
LD .tmp_vmlinux2 - due to: init/built-in.o fs/built-in.o .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.S - due to: .tmp_vmlinux2
AS .tmp_kallsyms2.o - due to: .tmp_kallsyms2.S
LD vmlinux - due to: init/built-in.o fs/built-in.o .tmp_kallsyms2.o
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux - due to vmlinux not in $(targets)
Building modules, stage 2.
AS arch/i386/boot/setup.o - due to: include/linux/compile.h
OBJCOPY arch/i386/boot/compressed/vmlinux.bin - due to: vmlinux
GZIP arch/i386/boot/compressed/vmlinux.bin.gz - due to: arch/i386/boot/compressed/vmlinux.bin
MODPOST 130 modules - due to target is PHONY
LD arch/i386/boot/compressed/piggy.o - due to: arch/i386/boot/compressed/vmlinux.bin.gz
LD arch/i386/boot/compressed/vmlinux - due to: arch/i386/boot/compressed/piggy.o
LD arch/i386/boot/setup - due to: arch/i386/boot/setup.o
OBJCOPY arch/i386/boot/vmlinux.bin - due to: arch/i386/boot/compressed/vmlinux
BUILD arch/i386/boot/bzImage - due to: arch/i386/boot/setup arch/i386/boot/vmlinux.bin
Root device is (254, 0)
Boot sector 512 bytes.
Setup is 6959 bytes.
System is 1567 kB
Kernel: arch/i386/boot/bzImage is ready (#16)
Luca
--
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.
On Tue, 9 Jan 2007, Andrew Morton wrote:
>
> > This new behavior of the kernel build system is likely to
> > make developers angry pretty quickly.
>
> That might motivate them to fix it ;)
Actually, how about just removing the incrementing version count entirely?
I realize that it's really really old, and has been there basically since
day one, but on the other hand, it's old not because it's fundamentally
important, but because it's just been maintained. How about just dropping
it entirely?
We have more useful _real_ versioning these days, with git commit ID's
etc.
Linus
Hi Jean !
On Tue, Jan 09, 2007 at 10:20:57AM +0100, Jean Delvare wrote:
> Hi all,
>
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
>
> I've tracked it down to include/linux/compile.h always being updated,
> and this is because .version is updated. I couldn't find what is
> causing .version to be updated each time though. Can anybody help
> there? Was this change made on purpose or is this a bug which we should
> fix?
it contains the build number (#X). You have it in the Makefile :
"expr 0$$(cat .old_version) + 1 >.version". I think you can block it
with a "chattr +i .version" and see if make complains.
Regards,
Willy
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 9 Jan 2007, Andrew Morton wrote:
> >
> > > This new behavior of the kernel build system is likely to
> > > make developers angry pretty quickly.
> >
> > That might motivate them to fix it ;)
>
> Actually, how about just removing the incrementing version count entirely?
I use it pretty commonly to answer the question "did I remember to install
that new kernel I just built before I rebooted"? By comparing `uname -a'
with $TOPDIR/.version.
From: Andrew Morton <[email protected]>
Date: Tue, 9 Jan 2007 15:25:34 -0800
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[email protected]> wrote:
>
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > >
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty quickly.
> > >
> > > That might motivate them to fix it ;)
> >
> > Actually, how about just removing the incrementing version count entirely?
>
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"? By comparing `uname -a'
> with $TOPDIR/.version.
Yeah me too :-)
Andrew Morton <[email protected]> writes:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[email protected]> wrote:
>
> >
> >
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > >
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty quickly.
> > >
> > > That might motivate them to fix it ;)
> >
> > Actually, how about just removing the incrementing version count entirely?
>
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"? By comparing `uname -a'
> with $TOPDIR/.version.
I even have scripts that require this to identify kernels. Please don't
remove it.
-Andi
On Tue, Jan 09, 2007 at 03:25:34PM -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[email protected]> wrote:
>
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > >
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty quickly.
> > >
> > > That might motivate them to fix it ;)
> >
> > Actually, how about just removing the incrementing version count
> > entirely?
>
> I use it pretty commonly to answer the question "did I remember to
> install that new kernel I just built before I rebooted"? By comparing
> `uname -a' with $TOPDIR/.version.
second that!
please do not remove this useful 'debug' feature :)
TIA,
Herbert
Hi Luca,
On Tue, 9 Jan 2007 22:55:27 +0100, Luca Tettamanti wrote:
> Jean Delvare <[email protected]> ha scritto:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or configuration or not. This increases the
> > build time quite a bit.
> >
> > I've tracked it down to include/linux/compile.h always being updated,
> > and this is because .version is updated. I couldn't find what is
> > causing .version to be updated each time though. Can anybody help
> > there? Was this change made on purpose or is this a bug which we should
> > fix?
>
> kronos:~/src/linux-2.6.git$ cat ../linux-build-git/include/linux/compile.h
> /* This file is auto generated, version 14 */
> /* SMP PREEMPT */
> #define UTS_MACHINE "i386"
> #define UTS_VERSION "#14 SMP PREEMPT Tue Jan 9 22:45:18 CET 2007"
> #define LINUX_COMPILE_TIME "22:45:18"
> #define LINUX_COMPILE_BY "kronos"
> #define LINUX_COMPILE_HOST "dreamland.darkstar.lan"
> #define LINUX_COMPILE_DOMAIN "darkstar.lan"
> #define LINUX_COMPILER "gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)"
>
> LINUX_COMPILE_TIME and UTS_VERSION differs at each rebuild. UTS_VERSION
> is responsible of rebuilding fs/proc/proc_misc.o; init/main.o uses just
> about everything, init/version.o requires UTS_VERSION.
That's not quite true, LINUX_COMPILE_TIME and UTS_VERSION are
explicitely excluded from the comparison when checking whether
linux/compile.h changed. This is done in scripts/mkcompile_h, and I
believe this part works properly. This script wasn't modified recently.
> I don't think it's a regression from earlier kernels though, is it?
It definitely is, which is why I am reporting it and am asking for it
to be fixed. I isolated the two responsible commits elsewhere in the
thread.
Thanks,
--
Jean Delvare
Hi Linus, Andrew,
On Tue, 9 Jan 2007 15:25:34 -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800, Linus Torvalds wrote:
> > Actually, how about just removing the incrementing version count entirely?
>
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"? By comparing `uname -a'
> with $TOPDIR/.version.
This will no longer work with the current state of things, as
$TOPDIR/.version keeps increasing.
> > (...) We have more useful _real_ versioning these days, with git commit
> > ID's etc.
These are completely different types of IDs. The .version number is a
local build ID and changes when one applies a local patch, or simply
changes a config option, and recompiles his/her kernel. The git ID of
course doesn't.
>From the other comments in this thread, it looks like the build ID is
something many people are interested in, so we can't just drop it.
--
Jean Delvare
On Jan 9 2007 15:21, Linus Torvalds wrote:
>
>Actually, how about just removing the incrementing version count entirely?
>
>I realize that it's really really old, and has been there basically since
>day one, but on the other hand, it's old not because it's fundamentally
>important, but because it's just been maintained. How about just dropping
>it entirely?
>
>We have more useful _real_ versioning these days, with git commit ID's
>etc.
Like other people said, scripts rely on it. Not just kernel-build
scripts or thelike. Note that this local build ID is _also_ in
/proc/version, meaning that every possible script out there has
code/regex to skip or read that one field.
E.g.
($ver, $builder, $gcc, $id, $flags, $date) =
($_ =~ /^Linux version (\S+) \((\S+)\) \((.*)\) (#\d+) (.*) ((?:Mon|Tue|Wed|Thu|Fri|Sat|Sun).*)/);
Oh well we could also put a static "#0" in there, but it also has
its uses (see replies from other people).
-`J'
--
Hi,
On Tue, 9 Jan 2007, Jean Delvare wrote:
> I tried a git bisect to find out what commit was reponsible for it, and
> the winner is...
>
> 8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
> commit 8993780a6e44fb4e7ed34e33458506a775356c6e
> Author: Linus Torvalds <[email protected]>
> Date: Mon Dec 11 09:28:46 2006 -0800
>
> [..]
> Reverting this from 2.6.20-rc1 made the build behave again, however I
> found that reverting it from 2.6.20-rc2 did _not_ fix the problem. I
> also had to revert the following patch to make things work as before
> again:
>
> commit ef129412b4cbd6686d0749612cb9b76e207271f4
> Author: Andrew Morton <[email protected]>
> Date: Fri Dec 22 01:12:01 2006 -0800
To make the list complete, this patch started all the mess:
commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
Author: Herbert Poetzl <[email protected]>
Date: Fri Dec 8 02:36:00 2006 -0800
[PATCH] Fix linux banner utsname information
and this tries to fix a problem in Andrew's patch:
commit d449db98d5d7d90f29f9f6e091b0e1d996184df1
Author: Mikael Pettersson <[email protected]>
Date: Fri Dec 29 16:48:09 2006 -0800
[PATCH] fix mrproper incompleteness
The patch below reverts pretty much everything and instead introduces a
seperate format string for proc.
bye, Roman
[PATCH] fix linux banner format string
Revert previous attempts at messing with the linux banner string and
simply use a separate format string for proc.
Signed-off-by: Roman Zippel <[email protected]>
---
Makefile | 31 +++++++++----------------------
fs/proc/proc_misc.c | 8 +-------
include/linux/kernel.h | 3 +++
init/Makefile | 10 +++++++++-
init/main.c | 8 --------
init/version.c | 10 ++++++++++
6 files changed, 32 insertions(+), 38 deletions(-)
Index: linux-2.6-git/fs/proc/proc_misc.c
===================================================================
--- linux-2.6-git.orig/fs/proc/proc_misc.c 2007-01-10 04:27:23.000000000 +0100
+++ linux-2.6-git/fs/proc/proc_misc.c 2007-01-10 04:33:01.000000000 +0100
@@ -47,7 +47,6 @@
#include <linux/vmalloc.h>
#include <linux/crash_dump.h>
#include <linux/pid_namespace.h>
-#include <linux/compile.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
#include <asm/io.h>
@@ -254,12 +253,7 @@ static int version_read_proc(char *page,
{
int len;
- /* FIXED STRING! Don't touch! */
- len = snprintf(page, PAGE_SIZE,
- "%s version %s"
- " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
- " (" LINUX_COMPILER ")"
- " %s\n",
+ len = snprintf(page, PAGE_SIZE, linux_proc_banner,
utsname()->sysname,
utsname()->release,
utsname()->version);
Index: linux-2.6-git/include/linux/kernel.h
===================================================================
--- linux-2.6-git.orig/include/linux/kernel.h 2007-01-10 04:26:37.000000000 +0100
+++ linux-2.6-git/include/linux/kernel.h 2007-01-10 04:27:05.000000000 +0100
@@ -17,6 +17,9 @@
#include <asm/byteorder.h>
#include <asm/bug.h>
+extern const char linux_banner[];
+extern const char linux_proc_banner[];
+
#define INT_MAX ((int)(~0U>>1))
#define INT_MIN (-INT_MAX - 1)
#define UINT_MAX (~0U)
Index: linux-2.6-git/init/main.c
===================================================================
--- linux-2.6-git.orig/init/main.c 2007-01-10 04:34:02.000000000 +0100
+++ linux-2.6-git/init/main.c 2007-01-10 14:20:02.000000000 +0100
@@ -50,9 +50,7 @@
#include <linux/buffer_head.h>
#include <linux/debug_locks.h>
#include <linux/lockdep.h>
-#include <linux/utsrelease.h>
#include <linux/pid_namespace.h>
-#include <linux/compile.h>
#include <linux/device.h>
#include <asm/io.h>
@@ -482,12 +480,6 @@ void __init __attribute__((weak)) smp_se
{
}
-static const char linux_banner[] =
- "Linux version " UTS_RELEASE
- " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
- " (" LINUX_COMPILER ")"
- " " UTS_VERSION "\n";
-
asmlinkage void __init start_kernel(void)
{
char * command_line;
Index: linux-2.6-git/init/version.c
===================================================================
--- linux-2.6-git.orig/init/version.c 2007-01-10 04:29:20.000000000 +0100
+++ linux-2.6-git/init/version.c 2007-01-10 04:41:11.000000000 +0100
@@ -33,3 +33,13 @@ struct uts_namespace init_uts_ns = {
},
};
EXPORT_SYMBOL_GPL(init_uts_ns);
+
+/* FIXED STRING! Don't touch! */
+const char __init linux_banner[] =
+ "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+ LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
+
+const char linux_proc_banner[] =
+ "%s version %s"
+ " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
+ " (" LINUX_COMPILER ") %s\n";
Index: linux-2.6-git/init/Makefile
===================================================================
--- linux-2.6-git.orig/init/Makefile 2007-01-10 04:44:59.000000000 +0100
+++ linux-2.6-git/init/Makefile 2007-01-10 14:06:15.000000000 +0100
@@ -15,6 +15,14 @@ clean-files := ../include/linux/compile.
# dependencies on generated files need to be listed explicitly
-$(obj)/main.o: include/linux/compile.h
$(obj)/version.o: include/linux/compile.h
+# compile.h changes depending on hostname, generation number, etc,
+# so we regenerate it always.
+# mkcompile_h will make sure to only update the
+# actual file if its content has changed.
+
+include/linux/compile.h: FORCE
+ @echo ' CHK $@'
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@ \
+ "$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT)" "$(CC) $(CFLAGS)"
Index: linux-2.6-git/Makefile
===================================================================
--- linux-2.6-git.orig/Makefile 2007-01-10 14:01:24.000000000 +0100
+++ linux-2.6-git/Makefile 2007-01-10 14:06:15.000000000 +0100
@@ -368,14 +368,10 @@ endif
# Detect when mixed targets is specified, and make a second invocation
# of make so .config is not included in this case either (for *config).
-PHONY += generated_headers
-
-generated_headers: include/linux/version.h include/linux/compile.h \
- include/linux/utsrelease.h
-
-no-dot-config-targets := generated_headers clean mrproper distclean \
+no-dot-config-targets := clean mrproper distclean \
cscope TAGS tags help %docs check% \
- headers_% kernelrelease kernelversion
+ include/linux/version.h headers_% \
+ kernelrelease kernelversion
config-targets := 0
mixed-targets := 0
@@ -738,16 +734,6 @@ debug_kallsyms: .tmp_map$(last_kallsyms)
endif # ifdef CONFIG_KALLSYMS
-# compile.h changes depending on hostname, generation number, etc,
-# so we regenerate it always.
-# mkcompile_h will make sure to only update the
-# actual file if its content has changed.
-
-include/linux/compile.h: FORCE
- @echo ' CHK $@'
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@ \
- "$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT)" "$(CC) $(CFLAGS)"
-
# vmlinux image - including updated kernel symbols
vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
ifdef CONFIG_HEADERS_CHECK
@@ -866,8 +852,8 @@ endif
# prepare2 creates a makefile if using a separate output directory
prepare2: prepare3 outputmakefile
-prepare1: prepare2 generated_headers include/asm include/config/auto.conf
-
+prepare1: prepare2 include/linux/version.h include/linux/utsrelease.h \
+ include/asm include/config/auto.conf
ifneq ($(KBUILD_MODULES),)
$(Q)mkdir -p $(MODVERDIR)
$(Q)rm -f $(MODVERDIR)/*
@@ -936,14 +922,14 @@ export INSTALL_HDR_PATH
HDRARCHES=$(filter-out generic,$(patsubst $(srctree)/include/asm-%/Kbuild,%,$(wildcard $(srctree)/include/asm-*/Kbuild)))
PHONY += headers_install_all
-headers_install_all: generated_headers scripts_basic FORCE
+headers_install_all: include/linux/version.h scripts_basic FORCE
$(Q)$(MAKE) $(build)=scripts scripts/unifdef
$(Q)for arch in $(HDRARCHES); do \
$(MAKE) ARCH=$$arch -f $(srctree)/scripts/Makefile.headersinst obj=include BIASMDIR=-bi-$$arch ;\
done
PHONY += headers_install
-headers_install: generated_headers scripts_basic FORCE
+headers_install: include/linux/version.h scripts_basic FORCE
@if [ ! -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
echo '*** Error: Headers not exportable for this architecture ($(ARCH))'; \
exit 1 ; fi
@@ -1040,7 +1026,8 @@ CLEAN_FILES += vmlinux System.map \
# Directories & files removed with 'make mrproper'
MRPROPER_DIRS += include/config include2 usr/include
MRPROPER_FILES += .config .config.old include/asm .version .old_version \
- include/linux/autoconf.h include/linux/utsrelease.h include/linux/version.h \
+ include/linux/autoconf.h include/linux/version.h \
+ include/linux/utsrelease.h \
Module.symvers tags TAGS cscope*
# clean - Delete most, but leave enough to build external modules
On Wed, Jan 10, Roman Zippel wrote:
> [PATCH] fix linux banner format string
>
> Revert previous attempts at messing with the linux banner string and
> simply use a separate format string for proc.
>
> Signed-off-by: Roman Zippel <[email protected]>
Acked-by: Olaf Hering <[email protected]>
Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[email protected]> wrote:
>
>>
>> On Tue, 9 Jan 2007, Andrew Morton wrote:
>>>> This new behavior of the kernel build system is likely to
>>>> make developers angry pretty quickly.
>>> That might motivate them to fix it ;)
>> Actually, how about just removing the incrementing version count entirely?
>
> I use it pretty commonly to answer the question "did I remember to install
> that new kernel I just built before I rebooted"? By comparing `uname -a'
> with $TOPDIR/.version.
Yup, we need to do the same thing in automated testing. Especially when
you're doing lilo -R, and don't know if you ended up fscking or panicing
during attempted reboot to new kernel.
Better would be a checksum of the vmlinux vs the running kernel text,
but that seems to be impossible due to code rewriting. Could we embed
a checksum in a little /proc file for this?
M.
Hi Martin,
On Wed, 10 Jan 2007 08:52:24 -0800, Martin J. Bligh wrote:
> Andrew Morton wrote:
> > I use it pretty commonly to answer the question "did I remember to install
> > that new kernel I just built before I rebooted"? By comparing `uname -a'
> > with $TOPDIR/.version.
>
> Yup, we need to do the same thing in automated testing. Especially when
> you're doing lilo -R, and don't know if you ended up fscking or panicing
> during attempted reboot to new kernel.
>
> Better would be a checksum of the vmlinux vs the running kernel text,
> but that seems to be impossible due to code rewriting. Could we embed
> a checksum in a little /proc file for this?
What would this allow that our current autoincrementing counter doesn't?
--
Jean Delvare
Hi Roman,
On Wed, 10 Jan 2007 14:45:28 +0100 (CET), Roman Zippel wrote:
> On Tue, 9 Jan 2007, Jean Delvare wrote:
>
> > I tried a git bisect to find out what commit was reponsible for it, and
> > the winner is...
> >
> > 8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
> > commit 8993780a6e44fb4e7ed34e33458506a775356c6e
> > Author: Linus Torvalds <[email protected]>
> > Date: Mon Dec 11 09:28:46 2006 -0800
> >
> > [..]
> > Reverting this from 2.6.20-rc1 made the build behave again, however I
> > found that reverting it from 2.6.20-rc2 did _not_ fix the problem. I
> > also had to revert the following patch to make things work as before
> > again:
> >
> > commit ef129412b4cbd6686d0749612cb9b76e207271f4
> > Author: Andrew Morton <[email protected]>
> > Date: Fri Dec 22 01:12:01 2006 -0800
>
> To make the list complete, this patch started all the mess:
>
> commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
> Author: Herbert Poetzl <[email protected]>
> Date: Fri Dec 8 02:36:00 2006 -0800
>
> [PATCH] Fix linux banner utsname information
>
> and this tries to fix a problem in Andrew's patch:
>
> commit d449db98d5d7d90f29f9f6e091b0e1d996184df1
> Author: Mikael Pettersson <[email protected]>
> Date: Fri Dec 29 16:48:09 2006 -0800
>
> [PATCH] fix mrproper incompleteness
>
> The patch below reverts pretty much everything and instead introduces a
> seperate format string for proc.
> (...)
> [PATCH] fix linux banner format string
>
> Revert previous attempts at messing with the linux banner string and
> simply use a separate format string for proc.
This fixes the problem I reported. Thanks Roman!
Linus, Andrew, if Roman's patch looks OK to you, can it please be
applied before 2.6.20 is released?
Thanks,
--
Jean Delvare
On Wed, 10 Jan 2007, Jean Delvare wrote:
>
> This fixes the problem I reported. Thanks Roman!
>
> Linus, Andrew, if Roman's patch looks OK to you, can it please be
> applied before 2.6.20 is released?
I applied it, but looking closer at it, it becomes clear that Roman didn't
understand the problem with that patch.
This part:
const char __init linux_banner[] =
CANNOT work, because the stupid SuSE tool that look into the kernel binary
searches for "Linux version " as the thing, and as such the "linux_banner"
has to be the _first_ thing to trigger it for it to work.
Which is why "__init" is wrong. It causes the linker to either put it at
the end of the thing (which would break the SuSE tool). Alternatively it
causes section mismatch problems ("init" and "const" don't work that well
together), in which case it might work, but only due to toolchain bugs.
Grr.
Linus
On Wed, Jan 10, Linus Torvalds wrote:
> Grr.
It did work for me for some reason, but I was wondering why it did work.
Cant we just invent a .data.uts section and put that into the
i386/x86_64/ia64/s390/powerpc vmlinux.lds.S files?
'"Linux version " UTS_RELEASE' in version.c
On Wed, 10 Jan 2007, Linus Torvalds wrote:
>
> Which is why "__init" is wrong. It causes the linker to either put it at
> the end of the thing (which would break the SuSE tool). Alternatively it
> causes section mismatch problems ("init" and "const" don't work that well
> together), in which case it might work, but only due to toolchain bugs.
>
> Grr.
Does anybody have the silly SuSE kernel version tool, and could test that
without the "__init" it all actually works?
Linus
On Wed, Jan 10, Olaf Hering wrote:
> On Wed, Jan 10, Linus Torvalds wrote:
>
> > Grr.
>
> It did work for me for some reason, but I was wondering why it did work.
with such a change, it will always be first. Tested on powerpc.
I could even add an ELF parser and look for the first bytes in the
.rodata section.
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 9fcc8d9..2050d8e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -11,6 +11,11 @@ #define ALIGN_FUNCTION() . = ALIGN(8)
#define RODATA \
. = ALIGN(4096); \
+ \
+ .rodata.uts : AT(ADDR(.data.uts) - LOAD_OFFSET) { \
+ *(.data.uts) \
+ } \
+ \
.rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \
VMLINUX_SYMBOL(__start_rodata) = .; \
*(.rodata) *(.rodata.*) \
diff --git a/init/version.c b/init/version.c
index 9d96d36..03f5916 100644
--- a/init/version.c
+++ b/init/version.c
@@ -19,6 +19,8 @@ #define version_string(a) version(a)
int version_string(LINUX_VERSION_CODE);
+const char __attribute__ ((__section__ (".rodata.uts"))) get_kernel_version[] = "fiXme Linux version " UTS_RELEASE;
+
struct uts_namespace init_uts_ns = {
.kref = {
.refcount = ATOMIC_INIT(2),
Linus Torvalds wrote:
>
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>> Which is why "__init" is wrong. It causes the linker to either put it at
>> the end of the thing (which would break the SuSE tool). Alternatively it
>> causes section mismatch problems ("init" and "const" don't work that well
>> together), in which case it might work, but only due to toolchain bugs.
>>
>> Grr.
>
> Does anybody have the silly SuSE kernel version tool, and could test that
> without the "__init" it all actually works?
Sure, will do.
-apw
On Wed, 10 Jan 2007, Olaf Hering wrote:
>
> On Wed, Jan 10, Linus Torvalds wrote:
>
> > Grr.
>
> It did work for me for some reason, but I was wondering why it did work.
Because you didn't have CIFS compiled in? Right now that's the only other
module that would trigger that particular string in memory, I think. So
purely by luck.
> Cant we just invent a .data.uts section and put that into the
> i386/x86_64/ia64/s390/powerpc vmlinux.lds.S files?
> '"Linux version " UTS_RELEASE' in version.c
I'd rather have the problem fixed by just not doing the binary scrounging
at all, or at the very least making the pattern-matching so strict that
there's no way other "Linux version " strings can trigger..
Linus
On Jan 10 2007 21:02, Olaf Hering wrote:
>On Wed, Jan 10, Olaf Hering wrote:
>
>with such a change, it will always be first. Tested on powerpc.
>I could even add an ELF parser and look for the first bytes in the
>.rodata section.
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
-`J'
--
> With such a change, you would not need to grep for it. You could use
> binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
> Maybe not the prettiest output, but guaranteed to contain only the
> banner.
objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)
Segher
Linus Torvalds wrote:
>
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>> Which is why "__init" is wrong. It causes the linker to either put it at
>> the end of the thing (which would break the SuSE tool). Alternatively it
>> causes section mismatch problems ("init" and "const" don't work that well
>> together), in which case it might work, but only due to toolchain bugs.
>>
>> Grr.
>
> Does anybody have the silly SuSE kernel version tool, and could test that
> without the "__init" it all actually works?
Ok, testing of this worked here across the board. All using the same
configs we used for the last round of testing on this issue. The main
problem machine ppc64 on SLES9 with CIFS enabled passes with this patch
plus __init removed.
Results on TKO.
Acked-by: Andy Whitcroft <[email protected]>
-apw
Hi,
On Wed, 10 Jan 2007, Linus Torvalds wrote:
> This part:
>
> const char __init linux_banner[] =
>
> CANNOT work, because the stupid SuSE tool that look into the kernel binary
> searches for "Linux version " as the thing, and as such the "linux_banner"
> has to be the _first_ thing to trigger it for it to work.
Unless the SuSE tool is completely stupid, it should actually work:
$ strings vmlinux | grep "Linux version"
Linux version 2.6.20-rc3-git7 (roman@squid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10 CET 2007
$
> Which is why "__init" is wrong. It causes the linker to either put it at
> the end of the thing (which would break the SuSE tool). Alternatively it
> causes section mismatch problems ("init" and "const" don't work that well
> together), in which case it might work, but only due to toolchain bugs.
The const could be dropped, but it shouldn't hurt much either...
bye, Roman
Roman Zippel wrote:
> Hi,
>
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>
>> This part:
>>
>> const char __init linux_banner[] =
>>
>> CANNOT work, because the stupid SuSE tool that look into the kernel binary
>> searches for "Linux version " as the thing, and as such the "linux_banner"
>> has to be the _first_ thing to trigger it for it to work.
>
> Unless the SuSE tool is completely stupid, it should actually work:
>
> $ strings vmlinux | grep "Linux version"
> Linux version 2.6.20-rc3-git7 (roman@squid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10 CET 2007
> $
Try compiling a kernel with CIFS enabled and you will find the output
somewhat different. And herein lies the rub, if the proc string is
__initdata then it falls to the bottom, and the tool takes the first
entry starting from 'Linux version ', which matches these incorrect
lines and the tool fails.
>
>> Which is why "__init" is wrong. It causes the linker to either put it at
>> the end of the thing (which would break the SuSE tool). Alternatively it
>> causes section mismatch problems ("init" and "const" don't work that well
>> together), in which case it might work, but only due to toolchain bugs.
>
> The const could be dropped, but it shouldn't hurt much either...
Longer term I do wonder if the linker section idea mooted elsewhere in
this thread would fly.
-apw
>> With such a change, you would not need to grep for it. You could use
>> binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
>> Maybe not the prettiest output, but guaranteed to contain only the
>> banner.
>
> objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)
For some reason that does not work.
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
$ objcopy -j .modinfo -O binary sonypi.ko /dev/stdout
has more success.
-`J'
--
Jan Engelhardt <[email protected]> writes:
> ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
> objcopy: stvfMiji: Permission denied
>
> Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Thu, 11 Jan 2007, Roman Zippel wrote:
>
> Unless the SuSE tool is completely stupid, it should actually work:
>
> $ strings vmlinux | grep "Linux version"
> Linux version 2.6.20-rc3-git7 (roman@squid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10 CET 2007
How about you do
git grep '".*Linux version .*"'
instead, and realize that it depends on your configuration option. Notably
CIFS.
In short: __init is actually a real *BUG*.
Linus
>> ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
>> objcopy: stvfMiji: Permission denied
>>
>> Why does it want to create a file there? This one works better:
>
> objcopy works in-place when only one file argument is passed.
Yeah. The >(...) syntax in my example provides such a file;
of course it's horribly broken in bash 3.x like so many other
things, but that's a different issue ;-)
Segher
On Jan 11 2007 18:39, Segher Boessenkool wrote:
>
>> > ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
>> > objcopy: stvfMiji: Permission denied
>> >
>> > Why does it want to create a file there? This one works better:
>>
>> objcopy works in-place when only one file argument is passed.
>
> Yeah. The >(...) syntax in my example provides such a file;
> of course it's horribly broken in bash 3.x like so many other
> things, but that's a different issue ;-)
I took () to be substituted, did not know you intended to write >(grep ...)
And that's not broken at all.
-`J'
--